x86: disable_mtrr_trim only need for x86_64
Subsystems (3)
PATCH 1/1 x86: disable_mtrr_trim only need for x86_64
[PATCH] x86: disable_mtrr_trim only need for x86_64
mtrr_trim_uncached_memory is only used in x86_64,
so disable_mtrr_trim is not needed for x86_32
arch/x86/kernel/cpu/mtrr/main.c +1 -1
@@ -624,6 +624,7 @@ static struct sysdev_driver mtrr_sysdev_driver = { .resume = mtrr_restore, }; +#ifdef CONFIG_X86_64 static int disable_mtrr_trim;static int __init disable_mtrr_trim_setup (char *str)
@@ -633,7 +634,6 @@ static int __init disable_mtrr_trim_setup(char *str) }early_param ("disable_mtrr_trim" , disable_mtrr_trim_setup); -#ifdef CONFIG_X86_64 /** * mtrr_trim_uncached_memory - trim RAM not covered by MTRRs *
H. Peter Anvin
reviewerQuoted 7 lines · Yinghai Lu
[PATCH] x86:
disable_mtrr_trimonly need forx86_64
mtrr_trim_uncached_memoryis only used inx86_64,so
disable_mtrr_trimis not needed forx86_32Signed-off-by Yinghai Lu <[email protected]>
That seems like a bug, and if so this patch goes the wrong direction. (If the 32-bit code has another solution for the same problem, they should be unified.)
The trimming of uncachable memory affects both 32- and 64-bit kernels; it's the same hardware, and even 32-bit kernels (with PAE) can access memory above 4 GB.
-hpa
Quoted 9 lines · H. Peter Anvin
Quoted 7 lines · Yinghai Lu
[PATCH] x86:
disable_mtrr_trimonly need forx86_64
mtrr_trim_uncached_memoryis only used inx86_64,so
disable_mtrr_trimis not needed forx86_32Signed-off-by Yinghai Lu <[email protected]>
Quoted 8 lines
That seems like a bug, and if so this patch goes the wrong direction. (If the 32-bit code has another solution for the same problem, they should be unified.)
The trimming of uncachable memory affects both 32- and 64-bit kernels; it's the same hardware, and even 32-bit kernels (with PAE) can access memory above 4 GB.
the trim fix for x86_64 is update end_pfn, and use that as max_pfn, and max_low_pfn in setup_arch.
but i386 is setup_arch is only using max_low_pfn.
to make you happy, the simple way is update e820 table so code could be unified between i386 and x86_64
update the e820 table by checking mtrr like checking gart hole...
is that OK?
YH
PATCH 1/1 x86_64: update e820 instead of updating end_pfn
In reply to H. Peter Anvin[PATCH] x86_64: update e820 instead of updating end_pfn
when mtrr is not covering all e820 table, need to trim the ram, need to update e820
so we can reuse some code for x86_32.
need to add early_identify_cpu for x86_32, and move mtrr_bp_init early
arch/x86/kernel/cpu/mtrr/main.c +14 -3
@@ -644,16 +644,17 @@ early_param("disable_mtrr_trim", disable_mtrr_trim_setup);* it from the kernel's allocation pools, warning the user with an obnoxious * message. */ -void __init mtrr_trim_uncached_memory (void ) +int __init mtrr_trim_uncached_memory (unsigned long end_pfn) {unsigned long i, base, size, highest_addr =0 , def, dummy;mtrr_type type; +u64 trim_start, trim_size;/* Make sure we only trim uncachable memory on Intel machines */ rdmsr (MTRRdefType_MSR, def, dummy); def &=0xff ;if (!is_cpu (INTEL ) || disable_mtrr_trim || def !=MTRR_TYPE_UNCACHABLE ) -return ; +return 0 ;/* Find highest cached pfn */ for (i =0 ; i < num_var_ranges; i++) {
@@ -673,8 +674,18 @@ void __init mtrr_trim_uncached_memory(void)"memory, trimmed %ld pages\n" , end_pfn - (highest_addr >> PAGE_SHIFT));printk (KERN_WARNING "***************\n" ); - end_pfn = highest_addr >> PAGE_SHIFT; + +printk (KERN_INFO "update e820 for mtrr\n" ); + trim_start = highest_addr; + trim_size = end_pfn; + trim_size <<=PAGE_SHIFT ; + trim_size -= trim_start; +add_memory_region (trim_start, trim_size,E820_RESERVED ); +update_e820 (); + return 1; } + +return 0 ; }#endif
arch/x86/kernel/setup_64.c +5 -2
@@ -324,9 +324,12 @@ void __init setup_arch(char **cmdline_p)* we are rounding upwards: */ end_pfn =e820_end_of_ram (); -/* Trim memory not covered by WB MTRRs */ +/* update e820 for memory not covered by WB MTRRs */ mtrr_bp_init (); -mtrr_trim_uncached_memory (); +if (mtrr_trim_uncached_memory (end_pfn)) { +e820_register_active_regions (0 ,0 ,-1UL ); + end_pfn =e820_end_of_ram (); + } num_physpages = end_pfn;
include/asm-x86/mtrr.h +3 -2
@@ -97,7 +97,7 @@ extern int mtrr_del_page (int reg, unsigned long base, unsigned long size);extern void mtrr_centaur_report_mcr (int mcr,u32 lo,u32 hi);extern void mtrr_ap_init (void );extern void mtrr_bp_init (void ); -extern void mtrr_trim_uncached_memory (void ); +extern int mtrr_trim_uncached_memory (unsigned long end_pfn);# else #define mtrr_save_fixed_ranges (arg) do {} while (0)#define mtrr_save_state () do {} while (0)
@@ -121,8 +121,9 @@ static __inline__ int mtrr_del_page (int reg, unsigned long base, {return -ENODEV ; } -static __inline__void mtrr_trim_uncached_memory (void ) +static __inline__int mtrr_trim_uncached_memory (unsigned long end_pfn) { +return 0 ; }static __inline__void mtrr_centaur_report_mcr (int mcr,u32 lo,u32 hi) {;}
Re: [PATCH] x86_64: update e820 instead of updating end_pfn
Quoted 4 lines · Yinghai Lu
[PATCH]
x86_64: update e820 instead of updatingend_pfnwhen mtrr is not covering all e820 table, need to trim the ram, need to update e820
ok, i like this approach even more - applied. Would you like to have a shot at adding mtrr_trim_uncached_memory() to 32-bit too? It is affected by the same problem (if not more).
Ingo
Re: [PATCH] x86_64: update e820 instead of updating end_pfn
Quoted 9 lines · On Sunday 20 January 2008 10:20:27 Ingo Molnar wrote:
Quoted 4 lines · Yinghai Lu
[PATCH]
x86_64: update e820 instead of updatingend_pfnwhen mtrr is not covering all e820 table, need to trim the ram, need to update e820
ok, i like this approach even more - applied. Would you like to have a shot at adding
mtrr_trim_uncached_memory()to 32-bit too? It is affected by the same problem (if not more).
What about the AMD fix I posted? You ignored that one for now but it is far more critical because it makes these patches break any modern AMD machine with >3GB.
-Andi
PATCH 1/1 x86_64: update e820 instead of updating end_pfn v2
[PATCH] x86_64: update e820 instead of updating end_pfn v2
need to be applied after andi's patch for AMD tom2 wb check
when mtrr is not covering all e820 table, need to trim the ram, need to update e820
so we can reuse some code for x86_32.
need to add early_identify_cpu for x86_32, and move mtrr_bp_init early
arch/x86/kernel/cpu/mtrr/main.c +22 -10
@@ -624,6 +624,7 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; +#ifdef CONFIG_X86_64 static int disable_mtrr_trim;static int __init disable_mtrr_trim_setup (char *str)
@@ -633,17 +634,16 @@ static int __init disable_mtrr_trim_setu }early_param ("disable_mtrr_trim" , disable_mtrr_trim_setup); -#ifdef CONFIG_X86_64 -/* * Newer AMD K8s and later CPUs have a special magic MSR way to force WB * for memory >4GB. Check for that here. * Note this won't check if the MTRRs < 4GB where the magic bit doesn't * apply to are wrong, but so far we don't know of any such case in the wild. */ +#define Tom2Enabled (1U << 21)#define Tom2ForceMemTypeWB (1U << 22) -static __init int amd_special_default_mtrr (void ) +static __init int amd_special_default_mtrr (unsigned long end_pfn) {u32 l, h;
@@ -661,8 +661,9 @@ static __init int amd_special_default_mt* Memory between 4GB and top of mem is forced WB by this magic bit. * Reserved before K8RevF, but should be zero there. */ -if (l & Tom2ForceMemTypeWB) -return 1 ; +if (l & Tom2Enabled) +if (l & Tom2ForceMemTypeWB) +return 1 ;return 0 ; }
@@ -676,10 +677,11 @@ static __init int amd_special_default_mt* memory off the end by adjusting end_pfn, removing it from the kernel's * allocation pools, warning the user with an obnoxious message. */ -void __init mtrr_trim_uncached_memory (void ) +int __init mtrr_trim_uncached_memory (unsigned long end_pfn) {unsigned long i, base, size, highest_addr =0 , def, dummy;mtrr_type type; +u64 trim_start, trim_size;/* * Make sure we only trim uncachable memory on machines that
@@ -688,7 +690,7 @@ void __init mtrr_trim_uncached_memory(vordmsr (MTRRdefType_MSR, def, dummy); def &=0xff ;if (!is_cpu (INTEL ) || disable_mtrr_trim || def !=MTRR_TYPE_UNCACHABLE ) -return ; +return 0 ;/* Find highest cached pfn */ for (i =0 ; i < num_var_ranges; i++) {
@@ -701,8 +703,8 @@ void __init mtrr_trim_uncached_memory(vo highest_addr = base + size; } -if (amd_special_default_mtrr ()) -return ; +if (amd_special_default_mtrr (end_pfn)) +return 0 ;if ((highest_addr >>PAGE_SHIFT ) < end_pfn) {printk (KERN_WARNING "***************\n" );
@@ -711,8 +713,18 @@ void __init mtrr_trim_uncached_memory(vo"memory, trimmed %ld pages\n" , end_pfn - (highest_addr >> PAGE_SHIFT));printk (KERN_WARNING "***************\n" ); - end_pfn = highest_addr >> PAGE_SHIFT; + +printk (KERN_INFO "update e820 for mtrr\n" ); + trim_start = highest_addr; + trim_size = end_pfn; + trim_size <<=PAGE_SHIFT ; + trim_size -= trim_start; +add_memory_region (trim_start, trim_size,E820_RESERVED ); +update_e820 (); + return 1; } + +return 0 ; }#endif
arch/x86/kernel/setup_64.c +5 -2
@@ -324,9 +324,12 @@ void __init setup_arch(char **cmdline_p)* we are rounding upwards: */ end_pfn =e820_end_of_ram (); -/* Trim memory not covered by WB MTRRs */ +/* update e820 for memory not covered by WB MTRRs */ mtrr_bp_init (); -mtrr_trim_uncached_memory (); +if (mtrr_trim_uncached_memory (end_pfn)) { +e820_register_active_regions (0 ,0 ,-1UL ); + end_pfn =e820_end_of_ram (); + } num_physpages = end_pfn;
include/asm-x86/mtrr.h +3 -2
@@ -97,7 +97,7 @@ extern int mtrr_del_page (int reg, unsigextern void mtrr_centaur_report_mcr (int mcr,u32 lo,u32 hi);extern void mtrr_ap_init (void );extern void mtrr_bp_init (void ); -extern void mtrr_trim_uncached_memory (void ); +extern int mtrr_trim_uncached_memory (unsigned long end_pfn);# else #define mtrr_save_fixed_ranges (arg) do {} while (0)#define mtrr_save_state () do {} while (0)
@@ -121,8 +121,9 @@ static __inline__ int mtrr_del_page (int {return -ENODEV ; } -static __inline__void mtrr_trim_uncached_memory (void ) +static __inline__int mtrr_trim_uncached_memory (unsigned long end_pfn) { +return 0 ; }static __inline__void mtrr_centaur_report_mcr (int mcr,u32 lo,u32 hi) {;}
PATCH 1/1 x86_32: trim memory by updating e820
[PATCH] x86_32: trim memory by updating e820
need to be applied after the patch for x86_64 version mtrr fix e820 v2.
when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for x86_64
here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early
compiled only, need someone test it.
arch/x86/kernel/cpu/common.c +8 -4
@@ -396,11 +396,9 @@ __setup("serialnumber", x86_serial_nr_se/* * This does the hard work of actually picking apart the CPU stuff... */ -void __cpuinit identify_cpu (struct cpuinfo_x86 *c) +void __cpuinit early_identify_cpu (struct cpuinfo_x86 *c) { -int i; - c->loops_per_jiffy = loops_per_jiffy; c->x86_cache_size =-1 ; c->x86_vendor =X86_VENDOR_UNKNOWN ; c->cpuid_level =-1 ;/* CPUID not detected */
@@ -424,7 +422,14 @@ void __cpuinit identify_cpu(struct cpuinif (this_cpu->c_identify) this_cpu->c_identify (c); +} +void __cpuinit identify_cpu (struct cpuinfo_x86 *c) +{ +int i; + + c->loops_per_jiffy = loops_per_jiffy; +early_identify_cpu (c);/* * Vendor-specific initialization. In this section we * canonicalize the feature flags, meaning if there are
@@ -485,7 +490,6 @@ void __init identify_boot_cpu(void)identify_cpu (&boot_cpu_data);sysenter_setup ();enable_sep_cpu (); -mtrr_bp_init (); }void __cpuinit identify_secondary_cpu (struct cpuinfo_x86 *c)
arch/x86/kernel/setup_32.c +8 -0
@@ -49,6 +49,7 @@#include <video/edid.h> +#include <asm/mtrr.h> #include <asm/apic.h> #include <asm/e820.h> #include <asm/mpspec.h>
@@ -747,6 +748,7 @@ void __init setup_arch(char **cmdline_p) bss_resource.start =virt_to_phys (&__bss_start); bss_resource.end =virt_to_phys (&__bss_stop)-1 ; +early_identify_cpu (&boot_cpu_data);parse_early_param ();if (user_defined_memmap) {
@@ -762,6 +764,12 @@ void __init setup_arch(char **cmdline_p) max_low_pfn =setup_memory (); +/* update e820 for memory not covered by WB MTRRs */ +mtrr_bp_init (); +if (mtrr_trim_uncached_memory (max_pfn)) { + max_low_pfn =setup_memory (); + } +#ifdef CONFIG_VMI /* * Must be after max_low_pfn is determined, and before kernel
arch/x86/kernel/cpu/mtrr/main.c +0 -2
@@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; -#ifdef CONFIG_X86_64 static int disable_mtrr_trim;static int __init disable_mtrr_trim_setup (char *str)
@@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(unsreturn 0 ; } -#endif /** * mtrr_bp_init - initialize mtrrs on the boot CPU
Documentation/kernel-parameters.txt +1 -1
@@ -575,7 +575,7 @@ and is between 256 and 4096 characters. See drivers/char/README.epca and Documentation/digiepca.txt. - disable_mtrr_trim [X86-64, Intel only] + disable_mtrr_trim [X86, Intel and AMD only] By default the kernel will trim any uncacheable memory out of your available memory pool based on MTRR settings. This parameter disables that behavior,
include/asm-x86/processor.h +1 -0
@@ -131,6 +131,7 @@ DECLARE_PER_CPU(struct cpuinfo_x86, cpu_void cpu_detect (struct cpuinfo_x86 *c); +extern void early_identify_cpu (struct cpuinfo_x86 *);extern void identify_cpu (struct cpuinfo_x86 *);extern void identify_boot_cpu (void );extern void identify_secondary_cpu (struct cpuinfo_x86 *);
arch/x86/kernel/e820_32.c +11 -0
@@ -827,3 +827,14 @@ static int __init parse_memmap(char *argreturn 0 ; }early_param ("memmap" , parse_memmap); +void __init update_e820 (void ) +{ +u8 nr_map; + + nr_map = e820.nr_map; +if (sanitize_e820_map (e820.map, &nr_map)) +return ; + e820.nr_map = nr_map; +printk (KERN_INFO "modified physical RAM map:\n" ); +print_memory_map ("modified" ); +}
include/asm-x86/e820_32.h +3 -0
@@ -19,6 +19,7 @@#ifndef __ASSEMBLY__extern struct e820map e820; +extern void update_e820 (void );extern int e820_all_mapped (u64 start,u64 end,unsigned type);extern int e820_any_mapped (u64 start,u64 end,unsigned type);
@@ -29,6 +30,8 @@ extern int is_memory_all_valid(u64 startextern int is_memory_all_reserved (u64 start,u64 end);extern void find_max_pfn (void );extern void register_bootmem_low_pages (unsigned long max_low_pfn); +extern void add_memory_region (unsigned long long start, +unsigned long long size,int type);extern void e820_register_memory (void );extern void limit_regions (unsigned long long size);extern void print_memory_map (char *who);
Re: [PATCH] x86_64: update e820 instead of updating end_pfn v2
In reply to Yinghai Luarch/x86/kernel/cpu/mtrr/main.c static __init int amd_special_default_mt · line 666
Quoted 13 lines
{
arch/x86/kernel/cpu/mtrr/main.c +3
-2u32 l, h;@@ -661,8 +661,9 @@ static __init int amd_special_default_mt* Memory between 4GB and top of mem is forced WB by this magic bit. * Reserved before K8RevF, but should be zero there. */ -if (l & Tom2ForceMemTypeWB) -return 1 ; +if (l & Tom2Enabled) +if (l & Tom2ForceMemTypeWB) +return 1 ;
That change is good agreed, but I would suggest to put it into a separate patch with a description
-Andi
Re: [PATCH] x86_64: update e820 instead of updating end_pfn v2
Quoted 16 lines · Andi Kleen
arch/x86/kernel/cpu/mtrr/main.c static __init int amd_special_default_mt · line 666
Quoted 12 lines
{
arch/x86/kernel/cpu/mtrr/main.c +3
-2u32 l, h;@@ -661,8 +661,9 @@ static __init int amd_special_default_mt* Memory between 4GB and top of mem is forced WB by this magic bit. * Reserved before K8RevF, but should be zero there. */ -if (l & Tom2ForceMemTypeWB) -return 1 ; +if (l & Tom2Enabled) +if (l & Tom2ForceMemTypeWB) +return 1 ;That change is good agreed, but I would suggest to put it into a separate patch with a description
Perhaps like this:
if (l & (Tom2Enabled|Tom2ForceMemTypeWB))
return 1;
Harvey
Re: [PATCH] x86_64: update e820 instead of updating end_pfn v2
Quoted 9 lines
Quoted 4 lines
That change is good agreed, but I would suggest to put it into a separate patch with a description
Perhaps like this:
if (l & (Tom2Enabled|Tom2ForceMemTypeWB))
return 1;
That's not equivalent.
-Andi
Re: [PATCH] x86_64: update e820 instead of updating end_pfn v2
Quoted 12 lines · Andi Kleen
Quoted 7 lines
Quoted 3 lines
That change is good agreed, but I would suggest to put it into a separate patch with a description
Perhaps like this:
if (l & (Tom2Enabled|Tom2ForceMemTypeWB))
return 1;That's not equivalent.
-Andi
The equivalence is:
if ((1 & Tom2Enabled) && (1 & Tom2ForceMemTypeWB))
return 1;
PATCH 1/1 x86_64: check if Tom2 is enabled
In reply to Andi Kleen[PATCH] x86_64: check if Tom2 is enabled
need to applied after andi's amd special tom2 wb check patch
in amd_special_default_mtrr need to check if TOM2 is enabled
arch/x86/kernel/cpu/mtrr/main.c +3 -1
@@ -641,6 +641,7 @@ early_param("disable_mtrr_trim", disable_mtrr_trim_setup);* Note this won't check if the MTRRs < 4GB where the magic bit doesn't * apply to are wrong, but so far we don't know of any such case in the wild. */ +#define Tom2Enabled (1U << 21)#define Tom2ForceMemTypeWB (1U << 22)static __init int amd_special_default_mtrr (void )
@@ -661,7 +662,8 @@ static __init int amd_special_default_mtrr(void)* Memory between 4GB and top of mem is forced WB by this magic bit. * Reserved before K8RevF, but should be zero there. */ -if (l & Tom2ForceMemTypeWB) +if ((l & (Tom2Enabled | Tom2ForceMemTypeWB)) == + (Tom2Enabled | Tom2ForceMemTypeWB))return 1 ;return 0 ; }
Re: [PATCH] x86_64: check if Tom2 is enabled
[Yinghai Lu - Sun, Jan 20, 2008 at 10:57:46PM -0800]
| [PATCH] x86_64: check if Tom2 is enabled | | need to applied after andi's amd special tom2 wb check patch | | in amd_special_default_mtrr need to check if TOM2 is enabled | | Signed-off-by: Yinghai Lu <[email protected]> | | diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c | index 289ba1a..26eed57 100644 | --- a/arch/x86/kernel/cpu/mtrr/main.c | +++ b/arch/x86/kernel/cpu/mtrr/main.c | @@ -641,6 +641,7 @@ early_param("disable_mtrr_trim", disable_mtrr_trim_setup); | * Note this won't check if the MTRRs < 4GB where the magic bit doesn't | * apply to are wrong, but so far we don't know of any such case in the wild. | */ | +#define Tom2Enabled (1U << 21) | #define Tom2ForceMemTypeWB (1U << 22) | | static __init int amd_special_default_mtrr(void) | @@ -661,7 +662,8 @@ static __init int amd_special_default_mtrr(void) | * Memory between 4GB and top of mem is forced WB by this magic bit. | * Reserved before K8RevF, but should be zero there. | */ | - if (l & Tom2ForceMemTypeWB) | + if ((l & (Tom2Enabled | Tom2ForceMemTypeWB)) == | + (Tom2Enabled | Tom2ForceMemTypeWB)) | return 1; | return 0; | }
is it possible to change 'l' and 'h' to 'low' and 'high'? 'cause 'l' does look like '1' (one) number...
- Cyrill -
H. Peter Anvin
reviewerRe: [PATCH] x86_64: check if Tom2 is enabled
Quoted 4 lines · Cyrill Gorcunov
is it possible to change 'l' and 'h' to 'low' and 'high'? 'cause 'l' does look like '1' (one) number...
I think you should use a different font. Otherwise we're soon in a position where we can't abbreviate anything that starts with L and keep using lower case throughout. That doesn't seem like a valid tradeoff to me.
There are plenty of fonts which have good visual distinction between l and 1 and O and 0.
-hpa
Re: [PATCH] x86_64: check if Tom2 is enabled
[H. Peter Anvin - Mon, Jan 21, 2008 at 09:39:16AM -0800]
Quoted 9 lines
Quoted 2 lines · Cyrill Gorcunov
is it possible to change 'l' and 'h' to 'low' and 'high'? 'cause 'l' does look like '1' (one) number...
I think you should use a different font. Otherwise we're soon in a position where we can't abbreviate anything that starts with L and keep using lower case throughout. That doesn't seem like a valid tradeoff to me.
Quoted 5 lines
There are plenty of fonts which have good visual distinction between l and 1 and O and 0.
-hpa
Hi Peter,
of course you're right!!! but... actually the only several symbols affected on this: 1-l, O-0 (maybe a few more, dunno) and that is the case for one-letter-ID only and that is so easy to avoid a such situation.
Anyway - as you wish ;)
- Cyrill -
Re: [PATCH] x86_64: check if Tom2 is enabled
In reply to Cyrill GorcunovQuoted 3 lines
is it possible to change 'l' and 'h' to 'low' and 'high'? 'cause 'l' does look like '1' (one) number...
It would be fine for me for someone to implement safe_rdtscll() and get rid of l and h everywhere. IMHO all the l and h accesses of MSRs are just harder to read and error prone over the ll 64bit variants.
But I didn't want to add it just for this.
-Andi
Re: [PATCH] x86_64: check if Tom2 is enabled
[Andi Kleen - Mon, Jan 21, 2008 at 07:03:27PM +0100]
| | > is it possible to change 'l' and 'h' to 'low' and 'high'? | > 'cause 'l' does look like '1' (one) number... | | It would be fine for me for someone to implement safe_rdtscll() and get rid | of l and h everywhere. IMHO all the l and h accesses of MSRs are just harder | to read and error prone over the ll 64bit variants. | | But I didn't want to add it just for this. | | -Andi |
clear enough, thanks
- Cyrill -
H. Peter Anvin
reviewerRe: [PATCH] x86_64: check if Tom2 is enabled
Quoted 11 lines · Cyrill Gorcunov
[Andi Kleen - Mon, Jan 21, 2008 at 07:03:27PM +0100]
| | > is it possible to change 'l' and 'h' to 'low' and 'high'? | > 'cause 'l' does look like '1' (one) number... | | It would be fine for me for someone to implement safe_rdtscll() and get rid | of l and h everywhere. IMHO all the l and h accesses of MSRs are just harder | to read and error prone over the ll 64bit variants. | | But I didn't want to add it just for this. |clear enough, thanks
Actually, I think it depends on the specific MSR - some use the halves for different data, whereas others treat it as a large 64-bit object.
Ironically enough, the way the MSR interfaces were carried into the 64-bit world makes the situation worse on 64 bits; edx:eax is the common way to represent a 64-bit value on 32 bits.
-hpa
Re: [PATCH] x86_64: check if Tom2 is enabled
Quoted 4 lines
Actually, I think it depends on the specific MSR - some use the halves for different data, whereas others treat it as a large 64-bit object.
Even if there are different fields in there it is still much cleaner and simpler if there is only a single number to manipulate.
Quoted 3 lines
Ironically enough, the way the MSR interfaces were carried into the 64-bit world makes the situation worse on 64 bits; edx:eax is the common way to represent a 64-bit value on 32 bits.
It's merely an implementation detail of the instruction. But even on 32bit there is about zero reason to expose that to C code. rdmsr/wrmsr et.al. should have been defined as 64bit only interface in Linux from day zero.
-Andi
Re: [PATCH] x86_64: update e820 instead of updating end_pfn
In reply to Ingo MolnarQuoted 11 lines · Ingo Molnar
Quoted 4 lines · Yinghai Lu
[PATCH]
x86_64: update e820 instead of updatingend_pfnwhen mtrr is not covering all e820 table, need to trim the ram, need to update e820
ok, i like this approach even more - applied. Would you like to have a shot at adding
mtrr_trim_uncached_memory()to 32-bit too? It is affected by the same problem (if not more).
for 32 bit, it could use the same mtrr_trim_uncached_memory.
but we need to move mtrr_bp_init calling into setup_arch.
YH
YH
A message that is not in the archive (sent off-list or not yet received): [email protected]
A message that is not in the archive (sent off-list or not yet received): [email protected]
PATCH 1/1 x86_32: trim memory by updating e820 v2
[PATCH] x86_32: trim memory by updating e820 v2
when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for x86_64
here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early
compiled test only, need someone test it
arch/x86/kernel/cpu/common.c +8 -4
@@ -396,11 +396,9 @@ __setup("serialnumber", x86_serial_nr_se/* * This does the hard work of actually picking apart the CPU stuff... */ -void __cpuinit identify_cpu (struct cpuinfo_x86 *c) +void __cpuinit early_identify_cpu (struct cpuinfo_x86 *c) { -int i; - c->loops_per_jiffy = loops_per_jiffy; c->x86_cache_size =-1 ; c->x86_vendor =X86_VENDOR_UNKNOWN ; c->cpuid_level =-1 ;/* CPUID not detected */
@@ -424,7 +422,14 @@ void __cpuinit identify_cpu(struct cpuinif (this_cpu->c_identify) this_cpu->c_identify (c); +} +void __cpuinit identify_cpu (struct cpuinfo_x86 *c) +{ +int i; + + c->loops_per_jiffy = loops_per_jiffy; +early_identify_cpu (c);/* * Vendor-specific initialization. In this section we * canonicalize the feature flags, meaning if there are
@@ -485,7 +490,6 @@ void __init identify_boot_cpu(void)identify_cpu (&boot_cpu_data);sysenter_setup ();enable_sep_cpu (); -mtrr_bp_init (); }void __cpuinit identify_secondary_cpu (struct cpuinfo_x86 *c)
arch/x86/kernel/setup_32.c +8 -0
@@ -49,6 +49,7 @@#include <video/edid.h> +#include <asm/mtrr.h> #include <asm/apic.h> #include <asm/e820.h> #include <asm/mpspec.h>
@@ -747,6 +748,7 @@ void __init setup_arch(char **cmdline_p) bss_resource.start =virt_to_phys (&__bss_start); bss_resource.end =virt_to_phys (&__bss_stop)-1 ; +early_identify_cpu (&boot_cpu_data);parse_early_param ();if (user_defined_memmap) {
@@ -762,6 +764,12 @@ void __init setup_arch(char **cmdline_p) max_low_pfn =setup_memory (); +/* update e820 for memory not covered by WB MTRRs */ +mtrr_bp_init (); +if (mtrr_trim_uncached_memory (max_pfn)) { + max_low_pfn =setup_memory (); + } +#ifdef CONFIG_VMI /* * Must be after max_low_pfn is determined, and before kernel
arch/x86/kernel/cpu/mtrr/main.c +0 -2
@@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; -#ifdef CONFIG_X86_64 static int disable_mtrr_trim;static int __init disable_mtrr_trim_setup (char *str)
@@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(unsreturn 0 ; } -#endif /** * mtrr_bp_init - initialize mtrrs on the boot CPU
Documentation/kernel-parameters.txt +1 -1
@@ -575,7 +575,7 @@ and is between 256 and 4096 characters. See drivers/char/README.epca and Documentation/digiepca.txt. - disable_mtrr_trim [X86-64, Intel only] + disable_mtrr_trim [X86, Intel and AMD only] By default the kernel will trim any uncacheable memory out of your available memory pool based on MTRR settings. This parameter disables that behavior,
include/asm-x86/processor.h +1 -0
@@ -131,6 +131,7 @@ DECLARE_PER_CPU(struct cpuinfo_x86, cpu_void cpu_detect (struct cpuinfo_x86 *c); +extern void early_identify_cpu (struct cpuinfo_x86 *);extern void identify_cpu (struct cpuinfo_x86 *);extern void identify_boot_cpu (void );extern void identify_secondary_cpu (struct cpuinfo_x86 *);
arch/x86/kernel/e820_32.c +11 -0
@@ -827,3 +827,14 @@ static int __init parse_memmap(char *argreturn 0 ; }early_param ("memmap" , parse_memmap); +void __init update_e820 (void ) +{ +u8 nr_map; + + nr_map = e820.nr_map; +if (sanitize_e820_map (e820.map, &nr_map)) +return ; + e820.nr_map = nr_map; +printk (KERN_INFO "modified physical RAM map:\n" ); +print_memory_map ("modified" ); +}
include/asm-x86/e820_32.h +3 -0
@@ -19,6 +19,7 @@#ifndef __ASSEMBLY__extern struct e820map e820; +extern void update_e820 (void );extern int e820_all_mapped (u64 start,u64 end,unsigned type);extern int e820_any_mapped (u64 start,u64 end,unsigned type);
@@ -29,6 +30,8 @@ extern int is_memory_all_valid(u64 startextern int is_memory_all_reserved (u64 start,u64 end);extern void find_max_pfn (void );extern void register_bootmem_low_pages (unsigned long max_low_pfn); +extern void add_memory_region (unsigned long long start, +unsigned long long size,int type);extern void e820_register_memory (void );extern void limit_regions (unsigned long long size);extern void print_memory_map (char *who);
arch/x86/kernel/setup_64.c +1 -3
@@ -158,8 +158,6 @@ .flags = IORESOURCE_RAM, }; -static void __cpuinit early_identify_cpu (struct cpuinfo_x86 *c); -#ifdef CONFIG_PROC_VMCORE /* elfcorehdr= specifies the location of elf core header * stored by the crashed kernel. This option will be passed
@@ -891,7 +889,7 @@/* Do some early cpuid on the boot CPU to get some parameter that are needed before check_bugs. Everything advanced is in identify_cpu below. */ -static void __cpuinit early_identify_cpu (struct cpuinfo_x86 *c) +void __cpuinit early_identify_cpu (struct cpuinfo_x86 *c) {u32 tfms, xlvl;
Re: [PATCH] x86_32: trim memory by updating e820 v2
Quoted 10 lines · Yinghai Lu
[PATCH]
x86_32: trim memory by updating e820 v2when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_identify_cpuforx86_32, and movemtrr_bp_initearlycompiled test only, need someone test it
I like this approach too. So as long as the E820 modification method works (i.e. we have some testers, maybe Justin can give it a try), you can add
or
as appropriate too.
Thanks,
Jesse
Re: [PATCH] x86_32: trim memory by updating e820 v2
Quoted 17 lines · Jesse Barnes
Quoted 10 lines · Yinghai Lu
[PATCH]
x86_32: trim memory by updating e820 v2when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_identify_cpuforx86_32, and movemtrr_bp_initearlycompiled test only, need someone test it
I like this approach too. So as long as the E820 modification method works (i.e. we have some testers, maybe Justin can give it a try), you can add
Signed-off-by Jesse Barnes <[email protected]>
Quoted 9 lines
or
Acked-by Jesse Barnes <[email protected]>as appropriate too.
Thanks,
Jesse
Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2
^^
I run x86_64 btw-- if there is a kernel.patch for x86_64 please let me know and I can test, thanks.
Justin.
Re: [PATCH] x86_32: trim memory by updating e820 v2
Quoted 30 lines · Justin Piszcz
Quoted 17 lines · Jesse Barnes
Quoted 10 lines · Yinghai Lu
[PATCH]
x86_32: trim memory by updating e820 v2when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_identify_cpuforx86_32, and movemtrr_bp_initearlycompiled test only, need someone test it
I like this approach too. So as long as the E820 modification method works (i.e. we have some testers, maybe Justin can give it a try), you can add
Signed-off-by Jesse Barnes <[email protected]>Quoted 9 lines
or
Acked-by Jesse Barnes <[email protected]>as appropriate too.
Thanks,
Jesse
Quoted 5 lines
Subject: Re: [PATCH]
x86_32: trim memory by updating e820 v2^^I run
x86_64btw-- if there is a kernel.patch forx86_64please let me know and I can test, thanks.
please get x86.git
git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
#--------------{ x86.git instructions }---------->
# Add Linus's tree as a remote
git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
# Add Ingo's tree as a remote
git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git
# With that setup, just run the following to get any changes you # don't have. It will also notice any new branches Ingo/Linus
# add to their repo. Look in .git/config afterwards, the format # to add new remotes is easy to figure out. git remote update #------------------------- git merge x86/master git merge x86/mm
and apply
[PATCH] x86_64: check if Tom2 is enabled
http://lkml.org/lkml/2008/1/21/20
[PATCH] x86_64: update e820 instead of updating end_pfn v3
http://lkml.org/lkml/2008/1/21/19
[PATCH] x86_32: trim memory by updating e820 v2
http://lkml.org/lkml/2008/1/21/18
YH
Re: [PATCH] x86_32: trim memory by updating e820 v2
Quoted 23 lines · Yinghai Lu
On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote:
please get x86.gitgit clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
#--------------{ x86.git instructions }---------->
# Add Linus's tree as a remote
git remote add linusgit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git# Add Ingo's tree as a remote
git remote add x86git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git# With that setup, just run the following to get any changes you # don't have. It will also notice any new branches Ingo/Linus
# add to their repo. Look in .git/config afterwards, the format # to add new remotes is easy to figure out. git remote update #------------------------- git merge x86/master git merge x86/mmand apply
Quoted 9 lines
[PATCH]
x86_64: check if Tom2 is enabled
http://lkml.org/lkml/2008/1/21/20
[PATCH]x86_64: update e820 instead of updatingend_pfnv3
http://lkml.org/lkml/2008/1/21/19
[PATCH]x86_32: trim memory by updating e820 v2
http://lkml.org/lkml/2008/1/21/18YH
Thanks, I am all patched up and ready to test, unfortunately one of my disks in my RAID 1 just died, I already filled out the advanced replacement form, I will test when I receive the replacement disk.
p34:~# lilo Fatal: Not all RAID-1 disks are active; use '-H' to install to active disks only p34:~# lilo -H Warning: Partial RAID-1 install on active disks only; booting is not failsafe
Warning: Faulty disk in RAID-1 array; boot with caution!!
Fatal: Unusual RAID bios device code: 0xFF p34:~#
Don't feel like mucking up my system at the moment.
Justin.
Re: [PATCH] x86_32: trim memory by updating e820 v2
Quoted 33 lines · Justin Piszcz
Quoted 30 lines · Yinghai Lu
On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote:
please get x86.gitgit clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
#--------------{ x86.git instructions }---------->
# Add Linus's tree as a remote
git remote add linusgit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git# Add Ingo's tree as a remote
git remote add x86git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git# With that setup, just run the following to get any changes you # don't have. It will also notice any new branches Ingo/Linus
# add to their repo. Look in .git/config afterwards, the format # to add new remotes is easy to figure out. git remote update #------------------------- git merge x86/master git merge x86/mmand apply
[PATCH]
x86_64: check if Tom2 is enabled
http://lkml.org/lkml/2008/1/21/20
[PATCH]x86_64: update e820 instead of updatingend_pfnv3
http://lkml.org/lkml/2008/1/21/19
[PATCH]x86_32: trim memory by updating e820 v2
http://lkml.org/lkml/2008/1/21/18
Quoted 6 lines
Quoted 2 lines
YH
Thanks, I am all patched up and ready to test, unfortunately one of my disks in my RAID 1 just died, I already filled out the advanced replacement form, I will test when I receive the replacement disk.
please get x86.git and apply
[PATCH] x86_32: trim memory by updating e820 v3
http://lkml.org/lkml/2008/1/22/394
Ingo already put other two into the tree.
Thanks
YH
Re: [PATCH] x86_32: trim memory by updating e820 v2
Quoted 45 lines · Yinghai Lu
Quoted 33 lines · Justin Piszcz
Quoted 30 lines · Yinghai Lu
On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote:
please get x86.gitgit clone
git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
cd linux-2.6
#--------------{ x86.git instructions }---------->
# Add Linus's tree as a remote
git remote add linusgit://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git# Add Ingo's tree as a remote
git remote add x86git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git# With that setup, just run the following to get any changes you # don't have. It will also notice any new branches Ingo/Linus
# add to their repo. Look in .git/config afterwards, the format # to add new remotes is easy to figure out. git remote update #------------------------- git merge x86/master git merge x86/mmand apply
[PATCH]
x86_64: check if Tom2 is enabled
http://lkml.org/lkml/2008/1/21/20
[PATCH]x86_64: update e820 instead of updatingend_pfnv3
http://lkml.org/lkml/2008/1/21/19
[PATCH]x86_32: trim memory by updating e820 v2
http://lkml.org/lkml/2008/1/21/18Quoted 6 lines
Quoted 2 lines
YH
Thanks, I am all patched up and ready to test, unfortunately one of my disks in my RAID 1 just died, I already filled out the advanced replacement form, I will test when I receive the replacement disk.
please get x86.git and apply
[PATCH]x86_32: trim memory by updating e820 v3
http://lkml.org/lkml/2008/1/22/394
Quoted 6 lines
Ingo already put other two into the tree.
Thanks
YH
Tried it, it worked successfully!
With stock kernel, previous way I had to use it was mem=8832M and top showed this:
top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10
Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers Swap: 16787768k total, 0k used, 16787768k free, 178528k cached
With kernel you mentioned and use e820 v3:
top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25
Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie
Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers
Swap: 16787768k total, 0k used, 16787768k free, 273928k cached
No append mem= required.
A full dmesg is attached so you can analyze the e820/MTRR mapping.
File: dmesg-e820v3patch.txt.bz2
Justin.
Re: [PATCH] x86_32: trim memory by updating e820 v2
Quoted 2 lines · Justin Piszcz
...
Quoted 13 lines
Tried it, it worked successfully!
With stock kernel, previous way I had to use it was mem=8832M and top showed this:
top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10
Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers Swap: 16787768k total, 0k used, 16787768k free, 178528k cachedWith kernel you mentioned and use e820 v3:
Quoted 8 lines
top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25
Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie
Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers
Swap: 16787768k total, 0k used, 16787768k free, 273928k cachedNo append mem= required.
thanks
any chance to try 32 bit with higemem64 option?
YH
Re: [PATCH] x86_32: trim memory by updating e820 v2
Quoted 27 lines · Yinghai Lu
Quoted 2 lines · Justin Piszcz
...
Quoted 13 lines
Tried it, it worked successfully!
With stock kernel, previous way I had to use it was mem=8832M and top showed this:
top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10
Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers Swap: 16787768k total, 0k used, 16787768k free, 178528k cachedWith kernel you mentioned and use e820 v3:
Quoted 8 lines
top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25
Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie
Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers
Swap: 16787768k total, 0k used, 16787768k free, 273928k cachedNo append mem= required.
Quoted 6 lines
thanks
any chance to try 32 bit with higemem64 option?
YH
My distribution is setup for 64-bit (64bit-clean) only, I do not have a 32-bit userland, so cannot help here, sorry.
Justin.
Re: [PATCH] x86_32: trim memory by updating e820 v2
In reply to Justin PiszczQuoted 19 lines · Justin Piszcz
Tried it, it worked successfully!
With stock kernel, previous way I had to use it was mem=8832M and top showed this:
top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10
Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers Swap: 16787768k total, 0k used, 16787768k free, 178528k cachedWith kernel you mentioned and use e820 v3:
top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25
Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie
Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers
Swap: 16787768k total, 0k used, 16787768k free, 273928k cached
Quoted 3 lines
No append mem= required.
A full dmesg is attached so you can analyze the e820/MTRR mapping.
thanks for testing it! The code indeed successfully trimmed your memory map by 64MB:
from:
[ 0.000000] BIOS-e820: 0000000100000000 - 000000022c000000 (usable)
to:
[ 0.000000] modified: 0000000100000000 - 0000000228000000 (usable) [ 0.000000] modified: 0000000228000000 - 000000022c000000 (reserved)
what happened on your box previously when you booted without any trimming - did it sometimes slow down or something like that?
Ingo
Re: [PATCH] x86_32: trim memory by updating e820 v2
Quoted 35 lines · Ingo Molnar
Quoted 19 lines · Justin Piszcz
Tried it, it worked successfully!
With stock kernel, previous way I had to use it was mem=8832M and top showed this:
top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10
Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers Swap: 16787768k total, 0k used, 16787768k free, 178528k cachedWith kernel you mentioned and use e820 v3:
top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25
Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie
Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st
Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers
Swap: 16787768k total, 0k used, 16787768k free, 273928k cachedQuoted 3 lines
No append mem= required.
A full dmesg is attached so you can analyze the e820/MTRR mapping.
thanks for testing it! The code indeed successfully trimmed your memory map by 64MB:
from:
[ 0.000000] BIOS-e820: 0000000100000000 - 000000022c000000 (usable)to:
Quoted 8 lines
[ 0.000000] modified: 0000000100000000 - 0000000228000000 (usable) [ 0.000000] modified: 0000000228000000 - 000000022c000000 (reserved)what happened on your box previously when you booted without any trimming - did it sometimes slow down or something like that?
Ingo
When I boot the box without any trimming it acts like a 286 or 386, takes about 10 minutes to boot (using raptor disks).
Justin.
Re: [PATCH] x86_32: trim memory by updating e820 v2
In reply to Yinghai LuQuoted 11 lines · Yinghai Lu
[PATCH]
x86_32: trim memory by updating e820 v2when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_identify_cpuforx86_32, and movemtrr_bp_initearlycompiled test only, need someone test it
i picked up the patch below, and it crashes with:
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
------------[ cut here ]------------ kernel BUG at arch/x86/mm/pageattr_32.c:327! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
Pid: 0, comm: swapper Not tainted (2.6.24-rc8 #15)
EIP: 0060:[<c0116a3f>] EFLAGS: 00010297 CPU: 0 EIP is at kernel_map_pages+0x52/0xb3
config and bootlog attached as well.
Ingo
------------------>
Subject: x86_32: trim memory by updating e820
From: Yinghai Lu <[email protected]>
when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for x86_64
here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early
compiled test only, need someone test it
--- Documentation/kernel-parameters.txt | 2 +- arch/x86/kernel/cpu/common.c | 12 ++++++++---- arch/x86/kernel/cpu/mtrr/main.c | 2 -- arch/x86/kernel/e820_32.c | 11 +++++++++++ arch/x86/kernel/setup_32.c | 7 +++++++ arch/x86/kernel/setup_64.c | 4 +--- include/asm-x86/e820_32.h | 3 +++ include/asm-x86/processor.h | 1 + 8 files changed, 32 insertions(+), 10 deletions(-)
Documentation/kernel-parameters.txt +1 -1
@@ -575,7 +575,7 @@ and is between 256 and 4096 characters. See drivers/char/README.epca and Documentation/digiepca.txt. - disable_mtrr_trim [X86-64, Intel only] + disable_mtrr_trim [X86, Intel and AMD only] By default the kernel will trim any uncacheable memory out of your available memory pool based on MTRR settings. This parameter disables that behavior,
arch/x86/kernel/cpu/common.c +8 -4
@@ -396,11 +396,9 @@ __setup("serialnumber", x86_serial_nr_se/* * This does the hard work of actually picking apart the CPU stuff... */ -void __cpuinit identify_cpu (struct cpuinfo_x86 *c) +void __cpuinit early_identify_cpu (struct cpuinfo_x86 *c) { -int i; - c->loops_per_jiffy = loops_per_jiffy; c->x86_cache_size =-1 ; c->x86_vendor =X86_VENDOR_UNKNOWN ; c->cpuid_level =-1 ;/* CPUID not detected */
@@ -424,7 +422,14 @@ void __cpuinit identify_cpu(struct cpuinif (this_cpu->c_identify) this_cpu->c_identify (c); +} +void __cpuinit identify_cpu (struct cpuinfo_x86 *c) +{ +int i; + + c->loops_per_jiffy = loops_per_jiffy; +early_identify_cpu (c);/* * Vendor-specific initialization. In this section we * canonicalize the feature flags, meaning if there are
@@ -485,7 +490,6 @@ void __init identify_boot_cpu(void)identify_cpu (&boot_cpu_data);sysenter_setup ();enable_sep_cpu (); -mtrr_bp_init (); }void __cpuinit identify_secondary_cpu (struct cpuinfo_x86 *c)
arch/x86/kernel/cpu/mtrr/main.c +0 -2
@@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; -#ifdef CONFIG_X86_64 static int disable_mtrr_trim;static int __init disable_mtrr_trim_setup (char *str)
@@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(unsreturn 0 ; } -#endif /** * mtrr_bp_init - initialize mtrrs on the boot CPU
arch/x86/kernel/e820_32.c +11 -0
@@ -749,3 +749,14 @@ static int __init parse_memmap(char *argreturn 0 ; }early_param ("memmap" , parse_memmap); +void __init update_e820 (void ) +{ +u8 nr_map; + + nr_map = e820.nr_map; +if (sanitize_e820_map (e820.map, &nr_map)) +return ; + e820.nr_map = nr_map; +printk (KERN_INFO "modified physical RAM map:\n" ); +print_memory_map ("modified" ); +}
arch/x86/kernel/setup_32.c +7 -0
@@ -49,6 +49,7 @@#include <video/edid.h> +#include <asm/mtrr.h> #include <asm/apic.h> #include <asm/e820.h> #include <asm/mpspec.h>
@@ -747,6 +748,7 @@ void __init setup_arch(char **cmdline_p) bss_resource.start =virt_to_phys (&__bss_start); bss_resource.end =virt_to_phys (&__bss_stop)-1 ; +early_identify_cpu (&boot_cpu_data);parse_early_param ();if (user_defined_memmap) {
@@ -762,6 +764,11 @@ void __init setup_arch(char **cmdline_p) max_low_pfn =setup_memory (); +/* update e820 for memory not covered by WB MTRRs */ +mtrr_bp_init (); +if (mtrr_trim_uncached_memory (max_pfn)) + max_low_pfn =setup_memory (); +#ifdef CONFIG_VMI /* * Must be after max_low_pfn is determined, and before kernel
arch/x86/kernel/setup_64.c +1 -3
@@ -157,8 +157,6 @@ static struct resource bss_resource = { .flags = IORESOURCE_RAM, }; -static void __cpuinit early_identify_cpu (struct cpuinfo_x86 *c); -#ifdef CONFIG_PROC_VMCORE /* elfcorehdr= specifies the location of elf core header * stored by the crashed kernel. This option will be passed
@@ -890,7 +888,7 @@ struct cpu_model_info {/* Do some early cpuid on the boot CPU to get some parameter that are needed before check_bugs. Everything advanced is in identify_cpu below. */ -static void __cpuinit early_identify_cpu (struct cpuinfo_x86 *c) +void __cpuinit early_identify_cpu (struct cpuinfo_x86 *c) {u32 tfms, xlvl;
include/asm-x86/e820_32.h +3 -0
@@ -19,12 +19,15 @@#ifndef __ASSEMBLY__extern struct e820map e820; +extern void update_e820 (void );extern int e820_all_mapped (unsigned long start,unsigned long end,unsigned type);extern int e820_any_mapped (u64 start,u64 end,unsigned type);extern void find_max_pfn (void );extern void register_bootmem_low_pages (unsigned long max_low_pfn); +extern void add_memory_region (unsigned long long start, +unsigned long long size,int type);extern void e820_register_memory (void );extern void limit_regions (unsigned long long size);extern void print_memory_map (char *who);
include/asm-x86/processor.h +1 -0
@@ -131,6 +131,7 @@ DECLARE_PER_CPU(struct cpuinfo_x86, cpu_void cpu_detect (struct cpuinfo_x86 *c); +extern void early_identify_cpu (struct cpuinfo_x86 *);extern void identify_cpu (struct cpuinfo_x86 *);extern void identify_boot_cpu (void );extern void identify_secondary_cpu (struct cpuinfo_x86 *);
#
# Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc8
# Tue Jan 22 17:33:45 2008
#
# CONFIG_64BIT is not setCONFIG_X86_32=y
# CONFIG_X86_64 is not setCONFIG_X86=y
# CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=yCONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=yCONFIG_MMU=yCONFIG_ZONE_DMA=yCONFIG_QUICKLIST=yCONFIG_GENERIC_ISA_DMA=yCONFIG_GENERIC_IOMAP=yCONFIG_GENERIC_BUG=y
# CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=yCONFIG_DMI=yCONFIG_RWSEM_GENERIC_SPINLOCK=y
# CONFIG_RWSEM_XCHGADD_ALGORITHM is not set
# CONFIG_ARCH_HAS_ILOG2_U32 is not set
# CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y
# CONFIG_GENERIC_TIME_VSYSCALL is not set
# CONFIG_ARCH_SETS_UP_PER_CPU_AREA is not set CONFIG_ARCH_SUPPORTS_OPROFILE=y
# CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y
# CONFIG_AUDIT_ARCH is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=yCONFIG_X86_SMP=yCONFIG_X86_32_SMP=yCONFIG_X86_HT=yCONFIG_X86_BIOS_REBOOT=yCONFIG_X86_TRAMPOLINE=yCONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
#
# General setup
#CONFIG_EXPERIMENTAL=yCONFIG_LOCK_KERNEL=yCONFIG_INIT_ENV_ARG_LIMIT=32CONFIG_LOCALVERSION=""CONFIG_LOCALVERSION_AUTO=yCONFIG_SWAP=y
# CONFIG_SYSVIPC is not set
# CONFIG_POSIX_MQUEUE is not set
# CONFIG_BSD_PROCESS_ACCT is not set
# CONFIG_TASKSTATS is not setCONFIG_USER_NS=yCONFIG_PID_NS=y
# CONFIG_AUDIT is not setCONFIG_IKCONFIG=y
# CONFIG_IKCONFIG_PROC is not setCONFIG_LOG_BUF_SHIFT=20CONFIG_CGROUPS=y
# CONFIG_CGROUP_DEBUG is not setCONFIG_CGROUP_NS=y
# CONFIG_CPUSETS is not setCONFIG_FAIR_GROUP_SCHED=yCONFIG_FAIR_USER_SCHED=y
# CONFIG_FAIR_CGROUP_SCHED is not setCONFIG_CGROUP_CPUACCT=yCONFIG_SYSFS_DEPRECATED=yCONFIG_RELAY=yCONFIG_BLK_DEV_INITRD=yCONFIG_INITRAMFS_SOURCE=""CONFIG_CC_OPTIMIZE_FOR_SIZE=yCONFIG_SYSCTL=y
# CONFIG_EMBEDDED is not setCONFIG_UID16=yCONFIG_SYSCTL_SYSCALL=yCONFIG_KALLSYMS=yCONFIG_KALLSYMS_ALL=yCONFIG_KALLSYMS_EXTRA_PASS=yCONFIG_HOTPLUG=yCONFIG_PRINTK=yCONFIG_BUG=yCONFIG_ELF_CORE=yCONFIG_BASE_FULL=yCONFIG_FUTEX=yCONFIG_ANON_INODES=yCONFIG_EPOLL=yCONFIG_SIGNALFD=yCONFIG_EVENTFD=yCONFIG_SHMEM=yCONFIG_VM_EVENT_COUNTERS=yCONFIG_SLUB_DEBUG=y
# CONFIG_SLAB is not setCONFIG_SLUB=y
# CONFIG_SLOB is not setCONFIG_SLABINFO=yCONFIG_RT_MUTEXES=y
# CONFIG_TINY_SHMEM is not setCONFIG_BASE_SMALL=0
# CONFIG_MODULES is not setCONFIG_STOP_MACHINE=yCONFIG_BLOCK=y
# CONFIG_LBD is not setCONFIG_BLK_DEV_IO_TRACE=y
# CONFIG_LSF is not set
# CONFIG_BLK_DEV_BSG is not set
#
# IO Schedulers
#CONFIG_IOSCHED_NOOP=y
# CONFIG_IOSCHED_AS is not set
# CONFIG_IOSCHED_DEADLINE is not setCONFIG_IOSCHED_CFQ=y
# CONFIG_DEFAULT_AS is not set
# CONFIG_DEFAULT_DEADLINE is not setCONFIG_DEFAULT_CFQ=y
# CONFIG_DEFAULT_NOOP is not setCONFIG_DEFAULT_IOSCHED="cfq"
#
# Processor type and features
#
# CONFIG_TICK_ONESHOT is not set
# CONFIG_NO_HZ is not set
# CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=yCONFIG_X86_PC=y
# CONFIG_X86_ELAN is not set
# CONFIG_X86_VOYAGER is not set
# CONFIG_X86_NUMAQ is not set
# CONFIG_X86_SUMMIT is not set
# CONFIG_X86_BIGSMP is not set
# CONFIG_X86_VISWS is not set
# CONFIG_X86_GENERICARCH is not set
# CONFIG_X86_ES7000 is not set
# CONFIG_X86_RDC321X is not set
# CONFIG_X86_VSMP is not set
# CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set # CONFIG_PARAVIRT_GUEST is not set CONFIG_M386=y
# CONFIG_M486 is not set
# CONFIG_M586 is not set
# CONFIG_M586TSC is not set
# CONFIG_M586MMX is not set
# CONFIG_M686 is not set
# CONFIG_MPENTIUMII is not set
# CONFIG_MPENTIUMIII is not set
# CONFIG_MPENTIUMM is not set
# CONFIG_MPENTIUM4 is not set
# CONFIG_MK6 is not set
# CONFIG_MK7 is not set
# CONFIG_MK8 is not set
# CONFIG_MCRUSOE is not set
# CONFIG_MEFFICEON is not set
# CONFIG_MWINCHIPC6 is not set
# CONFIG_MWINCHIP2 is not set
# CONFIG_MWINCHIP3D is not set
# CONFIG_MGEODEGX1 is not set
# CONFIG_MGEODE_LX is not set
# CONFIG_MCYRIXIII is not set
# CONFIG_MVIAC3_2 is not set
# CONFIG_MVIAC7 is not set
# CONFIG_MPSC is not set
# CONFIG_MCORE2 is not set
# CONFIG_GENERIC_CPU is not set
# CONFIG_X86_GENERIC is not set
# CONFIG_X86_CMPXCHG is not set CONFIG_X86_L1_CACHE_SHIFT=4 CONFIG_X86_PPRO_FENCE=y CONFIG_X86_F00F_BUG=y CONFIG_X86_MINIMUM_CPU_FAMILY=3
# CONFIG_HPET_TIMER is not set CONFIG_NR_CPUS=8CONFIG_SCHED_SMT=y
# CONFIG_SCHED_MC is not set CONFIG_PREEMPT_NONE=y
# CONFIG_PREEMPT_VOLUNTARY is not set
# CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y
# CONFIG_X86_MCE is not setCONFIG_VM86=yCONFIG_TOSHIBA=yCONFIG_I8K=yCONFIG_X86_REBOOTFIXUPS=y CONFIG_MICROCODE=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=yCONFIG_X86_CPUID=yCONFIG_NOHIGHMEM=y
# CONFIG_HIGHMEM4G is not set
# CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC0000000
# CONFIG_X86_PAE is not set CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y
# CONFIG_DISCONTIGMEM_MANUAL is not set
# CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y
# CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set CONFIG_SPLIT_PTLOCK_CPUS=4
# CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=1CONFIG_BOUNCE=yCONFIG_NR_QUICK=1CONFIG_VIRT_TO_BUS=y
# CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y
# CONFIG_EFI is not set CONFIG_IRQBALANCE=y
# CONFIG_SECCOMP is not set
# CONFIG_HZ_100 is not set
# CONFIG_HZ_250 is not setCONFIG_HZ_300=y
# CONFIG_HZ_1000 is not setCONFIG_HZ=300
# CONFIG_KEXEC is not set CONFIG_PHYSICAL_START=0x100000
# CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_ALIGN=0x100000 CONFIG_HOTPLUG_CPU=yCONFIG_COMPAT_VDSO=y
#
# Power management options
#CONFIG_PM=y
# CONFIG_PM_LEGACY is not set
# CONFIG_PM_DEBUG is not setCONFIG_SUSPEND_SMP_POSSIBLE=y
# CONFIG_SUSPEND is not setCONFIG_HIBERNATION_SMP_POSSIBLE=y
# CONFIG_HIBERNATION is not setCONFIG_ACPI=yCONFIG_ACPI_PROCFS=y
# CONFIG_ACPI_PROCFS_POWER is not setCONFIG_ACPI_SYSFS_POWER=yCONFIG_ACPI_PROC_EVENT=yCONFIG_ACPI_AC=yCONFIG_ACPI_BATTERY=y
# CONFIG_ACPI_BUTTON is not setCONFIG_ACPI_FAN=y
# CONFIG_ACPI_DOCK is not set
# CONFIG_ACPI_PROCESSOR is not set
# CONFIG_ACPI_ASUS is not set
# CONFIG_ACPI_TOSHIBA is not setCONFIG_ACPI_BLACKLIST_YEAR=0CONFIG_ACPI_DEBUG=yCONFIG_ACPI_DEBUG_FUNC_TRACE=yCONFIG_ACPI_EC=yCONFIG_ACPI_POWER=yCONFIG_ACPI_SYSTEM=yCONFIG_X86_PM_TIMER=y
# CONFIG_ACPI_CONTAINER is not setCONFIG_ACPI_SBS=y
#
# CPU Frequency scaling
#
# CONFIG_CPU_FREQ is not setCONFIG_CPU_IDLE=yCONFIG_CPU_IDLE_GOV_LADDER=y
#
# Bus options (PCI etc.)
#CONFIG_PCI=y
# CONFIG_PCI_GOBIOS is not set
# CONFIG_PCI_GOMMCONFIG is not set
# CONFIG_PCI_GODIRECT is not setCONFIG_PCI_GOANY=yCONFIG_PCI_BIOS=yCONFIG_PCI_DIRECT=yCONFIG_PCI_MMCONFIG=yCONFIG_PCI_DOMAINS=y
# CONFIG_PCIEPORTBUS is not setCONFIG_ARCH_SUPPORTS_MSI=yCONFIG_PCI_MSI=yCONFIG_PCI_LEGACY=y
# CONFIG_PCI_DEBUG is not setCONFIG_HT_IRQ=yCONFIG_ISA_DMA_API=y
# CONFIG_ISA is not setCONFIG_MCA=yCONFIG_MCA_LEGACY=y
# CONFIG_MCA_PROC_FS is not set
CONFIG_SCx200=y
# CONFIG_SCx200HR_TIMER is not setCONFIG_PCCARD=y
# CONFIG_PCMCIA_DEBUG is not set
# CONFIG_PCMCIA is not setCONFIG_CARDBUS=y
#
# PC-card bridges
#
# CONFIG_YENTA is not setCONFIG_HOTPLUG_PCI=y
# CONFIG_HOTPLUG_PCI_FAKE is not setCONFIG_HOTPLUG_PCI_COMPAQ=yCONFIG_HOTPLUG_PCI_COMPAQ_NVRAM=y
# CONFIG_HOTPLUG_PCI_IBM is not setCONFIG_HOTPLUG_PCI_ACPI=yCONFIG_HOTPLUG_PCI_ACPI_IBM=y
# CONFIG_HOTPLUG_PCI_CPCI is not setCONFIG_HOTPLUG_PCI_SHPC=y
#
# Executable file formats / Emulations
#CONFIG_BINFMT_ELF=yCONFIG_BINFMT_AOUT=y
# CONFIG_BINFMT_MISC is not set
#
# Networking
#CONFIG_NET=y
#
# Networking options
#CONFIG_PACKET=yCONFIG_PACKET_MMAP=yCONFIG_UNIX=yCONFIG_XFRM=yCONFIG_XFRM_USER=y
# CONFIG_XFRM_SUB_POLICY is not set
# CONFIG_XFRM_MIGRATE is not set
# CONFIG_NET_KEY is not setCONFIG_INET=yCONFIG_IP_MULTICAST=y
# CONFIG_IP_ADVANCED_ROUTER is not setCONFIG_IP_FIB_HASH=yCONFIG_IP_PNP=yCONFIG_IP_PNP_DHCP=yCONFIG_IP_PNP_BOOTP=yCONFIG_IP_PNP_RARP=y
# CONFIG_NET_IPIP is not setCONFIG_NET_IPGRE=y
# CONFIG_NET_IPGRE_BROADCAST is not set
# CONFIG_IP_MROUTE is not setCONFIG_ARPD=yCONFIG_SYN_COOKIES=y
# CONFIG_INET_AH is not set
# CONFIG_INET_ESP is not set
# CONFIG_INET_IPCOMP is not set
# CONFIG_INET_XFRM_TUNNEL is not set
# CONFIG_INET_TUNNEL is not setCONFIG_INET_XFRM_MODE_TRANSPORT=yCONFIG_INET_XFRM_MODE_TUNNEL=yCONFIG_INET_XFRM_MODE_BEET=yCONFIG_INET_LRO=yCONFIG_INET_DIAG=yCONFIG_INET_TCP_DIAG=y
# CONFIG_TCP_CONG_ADVANCED is not setCONFIG_TCP_CONG_CUBIC=yCONFIG_DEFAULT_TCP_CONG="cubic"CONFIG_TCP_MD5SIG=y
# CONFIG_IP_VS is not setCONFIG_IPV6=y
# CONFIG_IPV6_PRIVACY is not setCONFIG_IPV6_ROUTER_PREF=yCONFIG_IPV6_ROUTE_INFO=y
# CONFIG_IPV6_OPTIMISTIC_DAD is not set
# CONFIG_INET6_AH is not setCONFIG_INET6_ESP=yCONFIG_INET6_IPCOMP=yCONFIG_IPV6_MIP6=yCONFIG_INET6_XFRM_TUNNEL=yCONFIG_INET6_TUNNEL=yCONFIG_INET6_XFRM_MODE_TRANSPORT=yCONFIG_INET6_XFRM_MODE_TUNNEL=y
# CONFIG_INET6_XFRM_MODE_BEET is not setCONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=y
# CONFIG_IPV6_SIT is not setCONFIG_IPV6_TUNNEL=yCONFIG_IPV6_MULTIPLE_TABLES=yCONFIG_IPV6_SUBTREES=yCONFIG_NETLABEL=y
# CONFIG_NETWORK_SECMARK is not setCONFIG_NETFILTER=yCONFIG_NETFILTER_DEBUG=y
#
# Core Netfilter Configuration
#
# CONFIG_NETFILTER_NETLINK is not set
# CONFIG_NF_CONNTRACK_ENABLED is not set
# CONFIG_NF_CONNTRACK is not setCONFIG_NETFILTER_XTABLES=yCONFIG_NETFILTER_XT_TARGET_CLASSIFY=yCONFIG_NETFILTER_XT_TARGET_MARK=y
# CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not setCONFIG_NETFILTER_XT_TARGET_NFLOG=yCONFIG_NETFILTER_XT_TARGET_TCPMSS=yCONFIG_NETFILTER_XT_MATCH_COMMENT=y
# CONFIG_NETFILTER_XT_MATCH_DCCP is not set
# CONFIG_NETFILTER_XT_MATCH_DSCP is not setCONFIG_NETFILTER_XT_MATCH_ESP=yCONFIG_NETFILTER_XT_MATCH_LENGTH=y
# CONFIG_NETFILTER_XT_MATCH_LIMIT is not set
# CONFIG_NETFILTER_XT_MATCH_MAC is not setCONFIG_NETFILTER_XT_MATCH_MARK=y
# CONFIG_NETFILTER_XT_MATCH_POLICY is not setCONFIG_NETFILTER_XT_MATCH_MULTIPORT=y
# CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not setCONFIG_NETFILTER_XT_MATCH_QUOTA=y
# CONFIG_NETFILTER_XT_MATCH_REALM is not set
# CONFIG_NETFILTER_XT_MATCH_SCTP is not set
# CONFIG_NETFILTER_XT_MATCH_STATISTIC is not setCONFIG_NETFILTER_XT_MATCH_STRING=y
# CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set
# CONFIG_NETFILTER_XT_MATCH_TIME is not set
# CONFIG_NETFILTER_XT_MATCH_U32 is not set
# CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set
#
# IP: Netfilter Configuration
#
# CONFIG_IP_NF_QUEUE is not set
# CONFIG_IP_NF_IPTABLES is not setCONFIG_IP_NF_ARPTABLES=y
# CONFIG_IP_NF_ARPFILTER is not setCONFIG_IP_NF_ARP_MANGLE=y
#
# IPv6: Netfilter Configuration (EXPERIMENTAL)
#
# CONFIG_IP6_NF_QUEUE is not set
# CONFIG_IP6_NF_IPTABLES is not set
#
# DECnet: Netfilter Configuration
#
# CONFIG_DECNET_NF_GRABULATOR is not set
# CONFIG_IP_DCCP is not setCONFIG_IP_SCTP=y
# CONFIG_SCTP_DBG_MSG is not set
# CONFIG_SCTP_DBG_OBJCNT is not set
# CONFIG_SCTP_HMAC_NONE is not setCONFIG_SCTP_HMAC_SHA1=y
# CONFIG_SCTP_HMAC_MD5 is not setCONFIG_TIPC=y
# CONFIG_TIPC_ADVANCED is not set
# CONFIG_TIPC_DEBUG is not set
# CONFIG_ATM is not set
# CONFIG_BRIDGE is not set
# CONFIG_VLAN_8021Q is not setCONFIG_DECNET=y
# CONFIG_DECNET_ROUTER is not setCONFIG_LLC=yCONFIG_LLC2=y
# CONFIG_IPX is not setCONFIG_ATALK=yCONFIG_DEV_APPLETALK=yCONFIG_IPDDP=y
# CONFIG_IPDDP_ENCAP is not setCONFIG_IPDDP_DECAP=y
# CONFIG_X25 is not setCONFIG_LAPB=yCONFIG_ECONET=y
# CONFIG_ECONET_AUNUDP is not set
# CONFIG_ECONET_NATIVE is not set
# CONFIG_WAN_ROUTER is not set
# CONFIG_NET_SCHED is not set
#
# Network testing
#CONFIG_NET_PKTGEN=y
# CONFIG_HAMRADIO is not setCONFIG_IRDA=y
#
# IrDA protocols
#
# CONFIG_IRLAN is not set
# CONFIG_IRCOMM is not set
# CONFIG_IRDA_ULTRA is not set
#
# IrDA options
#CONFIG_IRDA_CACHE_LAST_LSAP=y
# CONFIG_IRDA_FAST_RR is not set
# CONFIG_IRDA_DEBUG is not set
#
# Infrared-port device drivers
#
#
# SIR device drivers
#CONFIG_IRTTY_SIR=y
#
# Dongle support
#CONFIG_DONGLE=y
# CONFIG_ESI_DONGLE is not set
# CONFIG_ACTISYS_DONGLE is not set
# CONFIG_TEKRAM_DONGLE is not set
# CONFIG_TOIM3232_DONGLE is not set
# CONFIG_LITELINK_DONGLE is not setCONFIG_MA600_DONGLE=yCONFIG_GIRBIL_DONGLE=y
# CONFIG_MCP2120_DONGLE is not set
# CONFIG_OLD_BELKIN_DONGLE is not set
# CONFIG_ACT200L_DONGLE is not setCONFIG_KINGSUN_DONGLE=y
# CONFIG_KSDAZZLE_DONGLE is not setCONFIG_KS959_DONGLE=y
#
# Old SIR device drivers
#
#
# Old Serial dongle support
#
#
# FIR device drivers
#CONFIG_USB_IRDA=yCONFIG_SIGMATEL_FIR=y
# CONFIG_NSC_FIR is not setCONFIG_WINBOND_FIR=yCONFIG_TOSHIBA_FIR=y
# CONFIG_SMC_IRCC_FIR is not set
# CONFIG_ALI_FIR is not setCONFIG_VLSI_FIR=y
# CONFIG_VIA_FIR is not setCONFIG_MCS_FIR=yCONFIG_BT=y
# CONFIG_BT_L2CAP is not set
# CONFIG_BT_SCO is not set
#
# Bluetooth device drivers
#CONFIG_BT_HCIUSB=yCONFIG_BT_HCIUSB_SCO=yCONFIG_BT_HCIUART=yCONFIG_BT_HCIUART_H4=y
# CONFIG_BT_HCIUART_BCSP is not set
# CONFIG_BT_HCIUART_LL is not set
# CONFIG_BT_HCIBCM203X is not setCONFIG_BT_HCIBPA10X=yCONFIG_BT_HCIBFUSB=yCONFIG_BT_HCIVHCI=yCONFIG_AF_RXRPC=yCONFIG_AF_RXRPC_DEBUG=yCONFIG_RXKAD=yCONFIG_FIB_RULES=y
#
# Wireless
#
# CONFIG_CFG80211 is not setCONFIG_WIRELESS_EXT=y
# CONFIG_MAC80211 is not setCONFIG_IEEE80211=yCONFIG_IEEE80211_DEBUG=yCONFIG_IEEE80211_CRYPT_WEP=yCONFIG_IEEE80211_CRYPT_CCMP=y
# CONFIG_IEEE80211_CRYPT_TKIP is not set
# CONFIG_IEEE80211_SOFTMAC is not setCONFIG_RFKILL=y
# CONFIG_RFKILL_INPUT is not setCONFIG_NET_9P=y
# CONFIG_NET_9P_FD is not set
# CONFIG_NET_9P_DEBUG is not set
#
# Device Drivers
#
#
# Generic Driver Options
#CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug"CONFIG_STANDALONE=yCONFIG_PREVENT_FIRMWARE_BUILD=yCONFIG_FW_LOADER=yCONFIG_DEBUG_DRIVER=y
# CONFIG_DEBUG_DEVRES is not set
# CONFIG_SYS_HYPERVISOR is not setCONFIG_CONNECTOR=yCONFIG_PROC_EVENTS=y
# CONFIG_MTD is not setCONFIG_PARPORT=y
# CONFIG_PARPORT_PC is not set
# CONFIG_PARPORT_GSC is not set
# CONFIG_PARPORT_AX88796 is not setCONFIG_PARPORT_1284=yCONFIG_PARPORT_NOT_PC=yCONFIG_PNP=y
# CONFIG_PNP_DEBUG is not set
#
# Protocols
#CONFIG_PNPACPI=yCONFIG_BLK_DEV=yCONFIG_BLK_DEV_FD=yCONFIG_BLK_CPQ_DA=y
# CONFIG_BLK_CPQ_CISS_DA is not setCONFIG_BLK_DEV_DAC960=y
# CONFIG_BLK_DEV_UMEM is not set
# CONFIG_BLK_DEV_COW_COMMON is not setCONFIG_BLK_DEV_LOOP=y
# CONFIG_BLK_DEV_CRYPTOLOOP is not setCONFIG_BLK_DEV_NBD=y
# CONFIG_BLK_DEV_SX8 is not set
# CONFIG_BLK_DEV_UB is not set
# CONFIG_BLK_DEV_RAM is not setCONFIG_CDROM_PKTCDVD=yCONFIG_CDROM_PKTCDVD_BUFFERS=8CONFIG_CDROM_PKTCDVD_WCACHE=y
# CONFIG_ATA_OVER_ETH is not set
# CONFIG_MISC_DEVICES is not set
# CONFIG_IDE is not set
#
# SCSI device support
#
# CONFIG_RAID_ATTRS is not setCONFIG_SCSI=yCONFIG_SCSI_DMA=yCONFIG_SCSI_TGT=yCONFIG_SCSI_NETLINK=yCONFIG_SCSI_PROC_FS=y
#
# SCSI support type (disk, tape, CD-ROM)
#CONFIG_BLK_DEV_SD=yCONFIG_CHR_DEV_ST=yCONFIG_CHR_DEV_OSST=y
# CONFIG_BLK_DEV_SR is not set
# CONFIG_CHR_DEV_SG is not setCONFIG_CHR_DEV_SCH=y
#
# Some SCSI devices (e.g. CD jukebox) support multiple LUNs #
# CONFIG_SCSI_MULTI_LUN is not set
# CONFIG_SCSI_CONSTANTS is not set
# CONFIG_SCSI_LOGGING is not set
# CONFIG_SCSI_SCAN_ASYNC is not set
#
# SCSI Transports
#CONFIG_SCSI_SPI_ATTRS=yCONFIG_SCSI_FC_ATTRS=yCONFIG_SCSI_FC_TGT_ATTRS=yCONFIG_SCSI_ISCSI_ATTRS=yCONFIG_SCSI_SAS_ATTRS=yCONFIG_SCSI_SAS_LIBSAS=y
# CONFIG_SCSI_SAS_ATA is not set
# CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set
# CONFIG_SCSI_SRP_ATTRS is not set
# CONFIG_SCSI_LOWLEVEL is not setCONFIG_ATA=y
# CONFIG_ATA_NONSTANDARD is not setCONFIG_ATA_ACPI=yCONFIG_SATA_AHCI=y
# CONFIG_SATA_SVW is not setCONFIG_ATA_PIIX=yCONFIG_SATA_MV=y
# CONFIG_SATA_NV is not set
# CONFIG_PDC_ADMA is not setCONFIG_SATA_QSTOR=y
# CONFIG_SATA_PROMISE is not set
# CONFIG_SATA_SX4 is not setCONFIG_SATA_SIL=y
# CONFIG_SATA_SIL24 is not set
# CONFIG_SATA_SIS is not setCONFIG_SATA_ULI=y
# CONFIG_SATA_VIA is not setCONFIG_SATA_VITESSE=yCONFIG_SATA_INIC162X=y
# CONFIG_PATA_ACPI is not setCONFIG_PATA_ALI=yCONFIG_PATA_AMD=yCONFIG_PATA_ARTOP=yCONFIG_PATA_ATIIXP=y
# CONFIG_PATA_CMD640_PCI is not set
# CONFIG_PATA_CMD64X is not setCONFIG_PATA_CS5520=y
# CONFIG_PATA_CS5530 is not setCONFIG_PATA_CS5535=y
# CONFIG_PATA_CS5536 is not set
# CONFIG_PATA_CYPRESS is not setCONFIG_PATA_EFAR=y
# CONFIG_ATA_GENERIC is not set
# CONFIG_PATA_HPT366 is not setCONFIG_PATA_HPT37X=y
# CONFIG_PATA_HPT3X2N is not setCONFIG_PATA_HPT3X3=yCONFIG_PATA_HPT3X3_DMA=y
# CONFIG_PATA_IT821X is not setCONFIG_PATA_IT8213=yCONFIG_PATA_JMICRON=yCONFIG_PATA_TRIFLEX=yCONFIG_PATA_MARVELL=yCONFIG_PATA_MPIIX=yCONFIG_PATA_OLDPIIX=y
# CONFIG_PATA_NETCELL is not setCONFIG_PATA_NS87410=y
# CONFIG_PATA_NS87415 is not setCONFIG_PATA_OPTI=yCONFIG_PATA_OPTIDMA=yCONFIG_PATA_PDC_OLD=yCONFIG_PATA_RADISYS=y
# CONFIG_PATA_RZ1000 is not setCONFIG_PATA_SC1200=yCONFIG_PATA_SERVERWORKS=yCONFIG_PATA_PDC2027X=y
# CONFIG_PATA_SIL680 is not set
# CONFIG_PATA_SIS is not setCONFIG_PATA_VIA=y
# CONFIG_PATA_WINBOND is not setCONFIG_MD=y
# CONFIG_BLK_DEV_MD is not setCONFIG_BLK_DEV_DM=y
# CONFIG_DM_DEBUG is not setCONFIG_DM_CRYPT=yCONFIG_DM_SNAPSHOT=y
# CONFIG_DM_MIRROR is not set
# CONFIG_DM_ZERO is not setCONFIG_DM_MULTIPATH=y
# CONFIG_DM_MULTIPATH_EMC is not set
# CONFIG_DM_MULTIPATH_RDAC is not set
# CONFIG_DM_MULTIPATH_HP is not set
# CONFIG_DM_DELAY is not setCONFIG_DM_UEVENT=y
# CONFIG_FUSION is not set
#
# IEEE 1394 (FireWire) support
#CONFIG_FIREWIRE=yCONFIG_FIREWIRE_OHCI=yCONFIG_FIREWIRE_SBP2=y
# CONFIG_IEEE1394 is not set
# CONFIG_I2O is not setCONFIG_MACINTOSH_DRIVERS=y
# CONFIG_MAC_EMUMOUSEBTN is not setCONFIG_NETDEVICES=y
# CONFIG_NETDEVICES_MULTIQUEUE is not set
# CONFIG_DUMMY is not setCONFIG_BONDING=yCONFIG_MACVLAN=y
# CONFIG_EQUALIZER is not setCONFIG_TUN=yCONFIG_VETH=yCONFIG_NET_SB1000=y
# CONFIG_ARCNET is not setCONFIG_PHYLIB=y
#
# MII PHY device drivers
#CONFIG_MARVELL_PHY=yCONFIG_DAVICOM_PHY=y
# CONFIG_QSEMI_PHY is not setCONFIG_LXT_PHY=yCONFIG_CICADA_PHY=y
# CONFIG_VITESSE_PHY is not set
# CONFIG_SMSC_PHY is not set
# CONFIG_BROADCOM_PHY is not set
# CONFIG_ICPLUS_PHY is not set
# CONFIG_FIXED_PHY is not set
# CONFIG_MDIO_BITBANG is not setCONFIG_NET_ETHERNET=yCONFIG_MII=yCONFIG_HAPPYMEAL=y
# CONFIG_SUNGEM is not setCONFIG_CASSINI=y
# CONFIG_NET_VENDOR_3COM is not setCONFIG_NET_VENDOR_SMC=yCONFIG_ULTRAMCA=yCONFIG_NET_TULIP=yCONFIG_DE2104X=yCONFIG_TULIP=yCONFIG_TULIP_MWI=y
# CONFIG_TULIP_MMIO is not set
# CONFIG_TULIP_NAPI is not set
# CONFIG_DE4X5 is not setCONFIG_WINBOND_840=yCONFIG_DM9102=y
# CONFIG_ULI526X is not setCONFIG_PCMCIA_XIRCOM=y
# CONFIG_AT1700 is not setCONFIG_DEPCA=y
# CONFIG_HP100 is not set
# CONFIG_NE2_MCA is not setCONFIG_IBMLANA=y
# CONFIG_IBM_NEW_EMAC_ZMII is not set
# CONFIG_IBM_NEW_EMAC_RGMII is not set
# CONFIG_IBM_NEW_EMAC_TAH is not set
# CONFIG_IBM_NEW_EMAC_EMAC4 is not setCONFIG_NET_PCI=yCONFIG_PCNET32=yCONFIG_PCNET32_NAPI=y
# CONFIG_AMD8111_ETH is not set
# CONFIG_ADAPTEC_STARFIRE is not set
# CONFIG_B44 is not setCONFIG_FORCEDETH=yCONFIG_FORCEDETH_NAPI=y
# CONFIG_EEPRO100 is not setCONFIG_E100=yCONFIG_FEALNX=y
# CONFIG_NATSEMI is not setCONFIG_NE2K_PCI=y
# CONFIG_8139CP is not setCONFIG_8139TOO=yCONFIG_8139TOO_PIO=y
# CONFIG_8139TOO_TUNE_TWISTER is not setCONFIG_8139TOO_8129=yCONFIG_8139_OLD_RX_RESET=y
# CONFIG_SIS900 is not setCONFIG_EPIC100=y
# CONFIG_SUNDANCE is not set
# CONFIG_TLAN is not setCONFIG_VIA_RHINE=yCONFIG_VIA_RHINE_MMIO=yCONFIG_VIA_RHINE_NAPI=y
# CONFIG_SC92031 is not set
# CONFIG_NET_POCKET is not setCONFIG_NETDEV_1000=yCONFIG_ACENIC=y
# CONFIG_ACENIC_OMIT_TIGON_I is not set
# CONFIG_DL2K is not setCONFIG_E1000=yCONFIG_E1000_NAPI=y
# CONFIG_E1000_DISABLE_PACKET_SPLIT is not set
# CONFIG_E1000E is not setCONFIG_IP1000=y
# CONFIG_NS83820 is not set
# CONFIG_HAMACHI is not set
# CONFIG_YELLOWFIN is not setCONFIG_R8169=y
# CONFIG_R8169_NAPI is not setCONFIG_SIS190=y
# CONFIG_SKGE is not setCONFIG_SKY2=yCONFIG_SKY2_DEBUG=yCONFIG_SK98LIN=yCONFIG_VIA_VELOCITY=yCONFIG_TIGON3=yCONFIG_BNX2=yCONFIG_QLA3XXX=yCONFIG_ATL1=yCONFIG_NETDEV_10000=y
# CONFIG_CHELSIO_T1 is not set
# CONFIG_CHELSIO_T3 is not setCONFIG_IXGBE=yCONFIG_IXGB=yCONFIG_IXGB_NAPI=y
# CONFIG_S2IO is not set
# CONFIG_MYRI10GE is not setCONFIG_NETXEN_NIC=yCONFIG_NIU=y
# CONFIG_MLX4_CORE is not setCONFIG_TEHUTI=y
# CONFIG_TR is not set
#
# Wireless LAN
#CONFIG_WLAN_PRE80211=y
# CONFIG_STRIP is not setCONFIG_WLAN_80211=yCONFIG_IPW2100=yCONFIG_IPW2100_MONITOR=yCONFIG_IPW2100_DEBUG=y
# CONFIG_IPW2200 is not set
# CONFIG_LIBERTAS is not setCONFIG_AIRO=y
# CONFIG_HERMES is not set
# CONFIG_ATMEL is not setCONFIG_PRISM54=yCONFIG_USB_ZD1201=y
# CONFIG_HOSTAP is not set
#
# USB Network Adapters
#CONFIG_USB_CATC=y
# CONFIG_USB_KAWETH is not set
# CONFIG_USB_PEGASUS is not setCONFIG_USB_RTL8150=yCONFIG_USB_USBNET=y
# CONFIG_USB_NET_AX8817X is not setCONFIG_USB_NET_CDCETHER=y
# CONFIG_USB_NET_DM9601 is not set
# CONFIG_USB_NET_GL620A is not setCONFIG_USB_NET_NET1080=y
# CONFIG_USB_NET_PLUSB is not set
# CONFIG_USB_NET_MCS7830 is not set
# CONFIG_USB_NET_RNDIS_HOST is not set
# CONFIG_USB_NET_CDC_SUBSET is not setCONFIG_USB_NET_ZAURUS=yCONFIG_WAN=y
# CONFIG_LANMEDIA is not setCONFIG_HDLC=y
# CONFIG_HDLC_RAW is not setCONFIG_HDLC_RAW_ETH=y
# CONFIG_HDLC_CISCO is not setCONFIG_HDLC_FR=y
# CONFIG_HDLC_PPP is not setCONFIG_HDLC_X25=y
# CONFIG_PCI200SYN is not setCONFIG_WANXL=yCONFIG_PC300=y
#
# Cyclades-PC300 MLPPP support is disabled.
#
#
# Refer to the file README.mlppp, provided by PC300 package. #CONFIG_PC300TOO=y
# CONFIG_FARSYNC is not set
# CONFIG_DLCI is not setCONFIG_SBNI=y
# CONFIG_SBNI_MULTILINE is not setCONFIG_FDDI=yCONFIG_DEFXX=yCONFIG_DEFXX_MMIO=y
# CONFIG_SKFP is not setCONFIG_HIPPI=y
# CONFIG_ROADRUNNER is not set
# CONFIG_PLIP is not set
# CONFIG_PPP is not set
# CONFIG_SLIP is not set
# CONFIG_NET_FC is not setCONFIG_SHAPER=yCONFIG_NETCONSOLE=y
# CONFIG_NETCONSOLE_DYNAMIC is not set CONFIG_NETPOLL=y
# CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=yCONFIG_ISDN=y
# CONFIG_ISDN_I4L is not setCONFIG_ISDN_CAPI=y
# CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON is not set # CONFIG_CAPI_TRACE is not set CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPI20=y CONFIG_ISDN_CAPI_CAPIFS_BOOL=y CONFIG_ISDN_CAPI_CAPIFS=y
#
# CAPI hardware drivers
#CONFIG_CAPI_AVM=y
# CONFIG_ISDN_DRV_AVMB1_B1PCI is not set
# CONFIG_ISDN_DRV_AVMB1_B1PCMCIA is not set
# CONFIG_ISDN_DRV_AVMB1_T1PCI is not set
# CONFIG_ISDN_DRV_AVMB1_C4 is not set
# CONFIG_CAPI_EICON is not set
# CONFIG_PHONE is not set
#
# Input device support
#CONFIG_INPUT=yCONFIG_INPUT_FF_MEMLESS=yCONFIG_INPUT_POLLDEV=y
#
# Userland interfaces
#CONFIG_INPUT_MOUSEDEV=yCONFIG_INPUT_MOUSEDEV_PSAUX=yCONFIG_INPUT_MOUSEDEV_SCREEN_X=1024CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768
# CONFIG_INPUT_JOYDEV is not setCONFIG_INPUT_EVDEV=y
# CONFIG_INPUT_EVBUG is not set
#
# Input Device Drivers
#CONFIG_INPUT_KEYBOARD=yCONFIG_KEYBOARD_ATKBD=y
# CONFIG_KEYBOARD_SUNKBD is not set
# CONFIG_KEYBOARD_LKKBD is not setCONFIG_KEYBOARD_XTKBD=y
# CONFIG_KEYBOARD_NEWTON is not setCONFIG_KEYBOARD_STOWAWAY=yCONFIG_INPUT_MOUSE=y
# CONFIG_MOUSE_PS2 is not set
# CONFIG_MOUSE_SERIAL is not set
# CONFIG_MOUSE_APPLETOUCH is not set
# CONFIG_MOUSE_VSXXXAA is not set
# CONFIG_INPUT_JOYSTICK is not setCONFIG_INPUT_TABLET=y
# CONFIG_TABLET_USB_ACECAD is not setCONFIG_TABLET_USB_AIPTEK=yCONFIG_TABLET_USB_GTCO=yCONFIG_TABLET_USB_KBTAB=y
# CONFIG_TABLET_USB_WACOM is not setCONFIG_INPUT_TOUCHSCREEN=yCONFIG_TOUCHSCREEN_FUJITSU=yCONFIG_TOUCHSCREEN_GUNZE=yCONFIG_TOUCHSCREEN_ELO=yCONFIG_TOUCHSCREEN_MTOUCH=y
# CONFIG_TOUCHSCREEN_MK712 is not setCONFIG_TOUCHSCREEN_PENMOUNT=yCONFIG_TOUCHSCREEN_TOUCHRIGHT=y
# CONFIG_TOUCHSCREEN_TOUCHWIN is not setCONFIG_TOUCHSCREEN_UCB1400=yCONFIG_TOUCHSCREEN_USB_COMPOSITE=yCONFIG_TOUCHSCREEN_USB_EGALAX=yCONFIG_TOUCHSCREEN_USB_PANJIT=yCONFIG_TOUCHSCREEN_USB_3M=yCONFIG_TOUCHSCREEN_USB_ITM=yCONFIG_TOUCHSCREEN_USB_ETURBO=yCONFIG_TOUCHSCREEN_USB_GUNZE=yCONFIG_TOUCHSCREEN_USB_DMC_TSC10=yCONFIG_TOUCHSCREEN_USB_IRTOUCH=yCONFIG_TOUCHSCREEN_USB_IDEALTEK=yCONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=yCONFIG_TOUCHSCREEN_USB_GOTOP=yCONFIG_INPUT_MISC=y
# CONFIG_INPUT_PCSPKR is not setCONFIG_INPUT_WISTRON_BTNS=yCONFIG_INPUT_ATLAS_BTNS=yCONFIG_INPUT_ATI_REMOTE=y
# CONFIG_INPUT_ATI_REMOTE2 is not setCONFIG_INPUT_KEYSPAN_REMOTE=y
# CONFIG_INPUT_POWERMATE is not setCONFIG_INPUT_YEALINK=yCONFIG_INPUT_UINPUT=y
#
# Hardware I/O ports
#CONFIG_SERIO=yCONFIG_SERIO_I8042=yCONFIG_SERIO_SERPORT=y
# CONFIG_SERIO_CT82C710 is not setCONFIG_SERIO_PARKBD=yCONFIG_SERIO_PCIPS2=yCONFIG_SERIO_LIBPS2=yCONFIG_SERIO_RAW=y
# CONFIG_GAMEPORT is not set
#
# Character devices
#CONFIG_VT=yCONFIG_VT_CONSOLE=yCONFIG_HW_CONSOLE=yCONFIG_VT_HW_CONSOLE_BINDING=y
# CONFIG_SERIAL_NONSTANDARD is not set
#
# Serial drivers
#CONFIG_SERIAL_8250=yCONFIG_SERIAL_8250_CONSOLE=yCONFIG_FIX_EARLYCON_MEM=yCONFIG_SERIAL_8250_PCI=yCONFIG_SERIAL_8250_PNP=yCONFIG_SERIAL_8250_NR_UARTS=4CONFIG_SERIAL_8250_RUNTIME_UARTS=4
# CONFIG_SERIAL_8250_EXTENDED is not set
# CONFIG_SERIAL_8250_MCA is not set
#
# Non-8250 serial port support
#CONFIG_SERIAL_CORE=yCONFIG_SERIAL_CORE_CONSOLE=y
# CONFIG_SERIAL_JSM is not setCONFIG_UNIX98_PTYS=y
# CONFIG_LEGACY_PTYS is not set
# CONFIG_PRINTER is not setCONFIG_PPDEV=yCONFIG_IPMI_HANDLER=yCONFIG_IPMI_PANIC_EVENT=yCONFIG_IPMI_PANIC_STRING=y
# CONFIG_IPMI_DEVICE_INTERFACE is not set
# CONFIG_IPMI_SI is not set
# CONFIG_IPMI_WATCHDOG is not set
# CONFIG_IPMI_POWEROFF is not setCONFIG_HW_RANDOM=y
# CONFIG_HW_RANDOM_INTEL is not setCONFIG_HW_RANDOM_AMD=y
# CONFIG_HW_RANDOM_GEODE is not setCONFIG_HW_RANDOM_VIA=yCONFIG_NVRAM=yCONFIG_RTC=y
# CONFIG_R3964 is not set
# CONFIG_APPLICOM is not setCONFIG_SONYPI=yCONFIG_MWAVE=y
# CONFIG_SCx200_GPIO is not set
CONFIG_PC8736x_GPIO=yCONFIG_NSC_GPIO=yCONFIG_CS5535_GPIO=y
# CONFIG_RAW_DRIVER is not setCONFIG_HPET=yCONFIG_HPET_RTC_IRQ=y
# CONFIG_HPET_MMAP is not set
# CONFIG_HANGCHECK_TIMER is not set
# CONFIG_TCG_TPM is not setCONFIG_TELCLOCK=yCONFIG_DEVPORT=yCONFIG_I2C=yCONFIG_I2C_BOARDINFO=y
# CONFIG_I2C_CHARDEV is not set
#
# I2C Algorithms
#CONFIG_I2C_ALGOBIT=yCONFIG_I2C_ALGOPCF=y
# CONFIG_I2C_ALGOPCA is not set
#
# I2C Hardware Bus support
#CONFIG_I2C_ALI1535=y
# CONFIG_I2C_ALI1563 is not setCONFIG_I2C_ALI15X3=yCONFIG_I2C_AMD756=y
# CONFIG_I2C_AMD756_S4882 is not set
# CONFIG_I2C_AMD8111 is not setCONFIG_I2C_I801=y
# CONFIG_I2C_I810 is not setCONFIG_I2C_PIIX4=yCONFIG_I2C_NFORCE2=y
# CONFIG_I2C_OCORES is not set
# CONFIG_I2C_PARPORT is not setCONFIG_I2C_PARPORT_LIGHT=yCONFIG_I2C_PROSAVAGE=y
# CONFIG_I2C_SAVAGE4 is not set
# CONFIG_I2C_SIMTEC is not set
# CONFIG_SCx200_ACB is not set
# CONFIG_I2C_SIS5595 is not set
# CONFIG_I2C_SIS630 is not setCONFIG_I2C_SIS96X=yCONFIG_I2C_TAOS_EVM=y
# CONFIG_I2C_TINY_USB is not setCONFIG_I2C_VIA=y
# CONFIG_I2C_VIAPRO is not setCONFIG_I2C_VOODOO3=y
#
# Miscellaneous I2C Chip support
#CONFIG_SENSORS_DS1337=y
# CONFIG_SENSORS_DS1374 is not set
# CONFIG_DS1682 is not set
# CONFIG_SENSORS_EEPROM is not setCONFIG_SENSORS_PCF8574=y
# CONFIG_SENSORS_PCA9539 is not setCONFIG_SENSORS_PCF8591=yCONFIG_SENSORS_MAX6875=y
# CONFIG_SENSORS_TSL2550 is not setCONFIG_I2C_DEBUG_CORE=y
# CONFIG_I2C_DEBUG_ALGO is not set
# CONFIG_I2C_DEBUG_BUS is not setCONFIG_I2C_DEBUG_CHIP=y
#
# SPI support
#
# CONFIG_SPI is not set
# CONFIG_SPI_MASTER is not set
# CONFIG_W1 is not setCONFIG_POWER_SUPPLY=y
# CONFIG_POWER_SUPPLY_DEBUG is not set
# CONFIG_PDA_POWER is not set
# CONFIG_BATTERY_DS2760 is not set
# CONFIG_HWMON is not setCONFIG_WATCHDOG=y
# CONFIG_WATCHDOG_NOWAYOUT is not set
#
# Watchdog Device Drivers
#
# CONFIG_SOFT_WATCHDOG is not setCONFIG_ACQUIRE_WDT=y
# CONFIG_ADVANTECH_WDT is not set
# CONFIG_ALIM1535_WDT is not setCONFIG_ALIM7101_WDT=yCONFIG_SC520_WDT=y
# CONFIG_EUROTECH_WDT is not set
# CONFIG_IB700_WDT is not setCONFIG_IBMASR=y
# CONFIG_WAFER_WDT is not set
# CONFIG_I6300ESB_WDT is not set
# CONFIG_ITCO_WDT is not set
# CONFIG_IT8712F_WDT is not set
# CONFIG_SC1200_WDT is not set
# CONFIG_SCx200_WDT is not setCONFIG_PC87413_WDT=yCONFIG_60XX_WDT=y
# CONFIG_SBC8360_WDT is not setCONFIG_SBC7240_WDT=yCONFIG_CPU5_WDT=y
# CONFIG_SMSC37B787_WDT is not setCONFIG_W83627HF_WDT=yCONFIG_W83697HF_WDT=yCONFIG_W83877F_WDT=yCONFIG_W83977F_WDT=y
# CONFIG_MACHZ_WDT is not setCONFIG_SBC_EPX_C3_WATCHDOG=y
#
# PCI-based Watchdog Cards
#CONFIG_PCIPCWATCHDOG=yCONFIG_WDTPCI=yCONFIG_WDT_501_PCI=y
#
# USB-based Watchdog Cards
#
# CONFIG_USBPCWATCHDOG is not set
#
# Sonics Silicon Backplane
#CONFIG_SSB_POSSIBLE=yCONFIG_SSB=yCONFIG_SSB_PCIHOST_POSSIBLE=y
# CONFIG_SSB_PCIHOST is not setCONFIG_SSB_DEBUG=y
#
# Multifunction device drivers
#
# CONFIG_MFD_SM501 is not set
#
# Multimedia devices
#
# CONFIG_VIDEO_DEV is not set
# CONFIG_DVB_CORE is not set
# CONFIG_DAB is not set
#
# Graphics support
#
# CONFIG_AGP is not setCONFIG_DRM=y
# CONFIG_DRM_TDFX is not setCONFIG_DRM_R128=yCONFIG_DRM_RADEON=yCONFIG_DRM_MGA=y
# CONFIG_DRM_VIA is not setCONFIG_DRM_SAVAGE=y
# CONFIG_VGASTATE is not set
# CONFIG_VIDEO_OUTPUT_CONTROL is not set
# CONFIG_FB is not setCONFIG_BACKLIGHT_LCD_SUPPORT=y
# CONFIG_LCD_CLASS_DEVICE is not setCONFIG_BACKLIGHT_CLASS_DEVICE=y
# CONFIG_BACKLIGHT_CORGI is not set
# CONFIG_BACKLIGHT_PROGEAR is not set
#
# Display device support
#CONFIG_DISPLAY_SUPPORT=y
#
# Display hardware drivers
#
#
# Console display driver support
#CONFIG_VGA_CONSOLE=yCONFIG_VGACON_SOFT_SCROLLBACK=yCONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64CONFIG_VIDEO_SELECT=yCONFIG_DUMMY_CONSOLE=y
#
# Sound
#
# CONFIG_SOUND is not setCONFIG_AC97_BUS=yCONFIG_HID_SUPPORT=yCONFIG_HID=yCONFIG_HID_DEBUG=y
# CONFIG_HIDRAW is not set
#
# USB Input Devices
#
# CONFIG_USB_HID is not set
#
# USB HID Boot Protocol drivers
#CONFIG_USB_KBD=yCONFIG_USB_MOUSE=yCONFIG_USB_SUPPORT=yCONFIG_USB_ARCH_HAS_HCD=yCONFIG_USB_ARCH_HAS_OHCI=yCONFIG_USB_ARCH_HAS_EHCI=yCONFIG_USB=yCONFIG_USB_DEBUG=y
#
# Miscellaneous USB options
#CONFIG_USB_DEVICEFS=yCONFIG_USB_DEVICE_CLASS=yCONFIG_USB_DYNAMIC_MINORS=yCONFIG_USB_SUSPEND=y
# CONFIG_USB_PERSIST is not set
# CONFIG_USB_OTG is not set
#
# USB Host Controller Drivers
#CONFIG_USB_EHCI_HCD=yCONFIG_USB_EHCI_SPLIT_ISO=y
# CONFIG_USB_EHCI_ROOT_HUB_TT is not setCONFIG_USB_EHCI_TT_NEWSCHED=yCONFIG_USB_ISP116X_HCD=yCONFIG_USB_OHCI_HCD=y
# CONFIG_USB_OHCI_HCD_SSB is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set
# CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not setCONFIG_USB_OHCI_LITTLE_ENDIAN=yCONFIG_USB_UHCI_HCD=yCONFIG_USB_U132_HCD=yCONFIG_USB_SL811_HCD=yCONFIG_USB_R8A66597_HCD=y
#
# USB Device Class drivers
#
# CONFIG_USB_ACM is not setCONFIG_USB_PRINTER=y
#
# NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' #
#
# may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=y CONFIG_USB_STORAGE_DEBUG=y # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set CONFIG_USB_STORAGE_USBAT=y # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set CONFIG_USB_STORAGE_ALAUDA=y CONFIG_USB_STORAGE_KARMA=y # CONFIG_USB_LIBUSUAL is not set
#
# USB Imaging devices
#CONFIG_USB_MDC800=y
# CONFIG_USB_MICROTEK is not setCONFIG_USB_MON=y
#
# USB port drivers
#CONFIG_USB_USS720=y
#
# USB Serial Converter support
#CONFIG_USB_SERIAL=y
# CONFIG_USB_SERIAL_CONSOLE is not set
# CONFIG_USB_SERIAL_GENERIC is not setCONFIG_USB_SERIAL_AIRCABLE=y
# CONFIG_USB_SERIAL_AIRPRIME is not setCONFIG_USB_SERIAL_ARK3116=y
# CONFIG_USB_SERIAL_BELKIN is not setCONFIG_USB_SERIAL_CH341=y
# CONFIG_USB_SERIAL_WHITEHEAT is not setCONFIG_USB_SERIAL_DIGI_ACCELEPORT=yCONFIG_USB_SERIAL_CP2101=y
# CONFIG_USB_SERIAL_CYPRESS_M8 is not setCONFIG_USB_SERIAL_EMPEG=y
# CONFIG_USB_SERIAL_FTDI_SIO is not set
# CONFIG_USB_SERIAL_FUNSOFT is not set
# CONFIG_USB_SERIAL_VISOR is not set
# CONFIG_USB_SERIAL_IPAQ is not set
# CONFIG_USB_SERIAL_IR is not setCONFIG_USB_SERIAL_EDGEPORT=yCONFIG_USB_SERIAL_EDGEPORT_TI=y
# CONFIG_USB_SERIAL_GARMIN is not setCONFIG_USB_SERIAL_IPW=y
# CONFIG_USB_SERIAL_KEYSPAN_PDA is not setCONFIG_USB_SERIAL_KEYSPAN=y
# CONFIG_USB_SERIAL_KEYSPAN_MPR is not set
# CONFIG_USB_SERIAL_KEYSPAN_USA28 is not setCONFIG_USB_SERIAL_KEYSPAN_USA28X=y
# CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not setCONFIG_USB_SERIAL_KEYSPAN_USA28XB=yCONFIG_USB_SERIAL_KEYSPAN_USA19=y
# CONFIG_USB_SERIAL_KEYSPAN_USA18X is not setCONFIG_USB_SERIAL_KEYSPAN_USA19W=yCONFIG_USB_SERIAL_KEYSPAN_USA19QW=y
# CONFIG_USB_SERIAL_KEYSPAN_USA19QI is not setCONFIG_USB_SERIAL_KEYSPAN_USA49W=yCONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y
# CONFIG_USB_SERIAL_KLSI is not setCONFIG_USB_SERIAL_KOBIL_SCT=yCONFIG_USB_SERIAL_MCT_U232=y
# CONFIG_USB_SERIAL_MOS7720 is not setCONFIG_USB_SERIAL_MOS7840=y
# CONFIG_USB_SERIAL_NAVMAN is not setCONFIG_USB_SERIAL_PL2303=y
# CONFIG_USB_SERIAL_OTI6858 is not setCONFIG_USB_SERIAL_HP4X=y
# CONFIG_USB_SERIAL_SAFE is not set
# CONFIG_USB_SERIAL_SIERRAWIRELESS is not setCONFIG_USB_SERIAL_TI=yCONFIG_USB_SERIAL_CYBERJACK=y
# CONFIG_USB_SERIAL_XIRCOM is not setCONFIG_USB_SERIAL_OPTION=y
# CONFIG_USB_SERIAL_OMNINET is not set
# CONFIG_USB_SERIAL_DEBUG is not setCONFIG_USB_EZUSB=y
#
# USB Miscellaneous drivers
#CONFIG_USB_EMI62=y
# CONFIG_USB_EMI26 is not setCONFIG_USB_ADUTUX=yCONFIG_USB_AUERSWALD=yCONFIG_USB_RIO500=y
# CONFIG_USB_LEGOTOWER is not set
# CONFIG_USB_LCD is not set
# CONFIG_USB_BERRY_CHARGE is not setCONFIG_USB_LED=yCONFIG_USB_CYPRESS_CY7C63=yCONFIG_USB_CYTHERM=y
# CONFIG_USB_PHIDGET is not set
# CONFIG_USB_IDMOUSE is not setCONFIG_USB_FTDI_ELAN=yCONFIG_USB_APPLEDISPLAY=yCONFIG_USB_SISUSBVGA=y
# CONFIG_USB_SISUSBVGA_CON is not set
# CONFIG_USB_LD is not setCONFIG_USB_TRANCEVIBRATOR=yCONFIG_USB_IOWARRIOR=yCONFIG_USB_TEST=y
#
# USB DSL modem support
#
#
# USB Gadget Support
#
# CONFIG_USB_GADGET is not set
# CONFIG_MMC is not setCONFIG_NEW_LEDS=yCONFIG_LEDS_CLASS=y
#
# LED drivers
#
#
# LED Triggers
#
# CONFIG_LEDS_TRIGGERS is not setCONFIG_INFINIBAND=y
# CONFIG_INFINIBAND_USER_MAD is not set
# CONFIG_INFINIBAND_USER_ACCESS is not setCONFIG_INFINIBAND_ADDR_TRANS=y
# CONFIG_INFINIBAND_MTHCA is not setCONFIG_INFINIBAND_AMSO1100=y
# CONFIG_INFINIBAND_AMSO1100_DEBUG is not set
# CONFIG_MLX4_INFINIBAND is not setCONFIG_INFINIBAND_IPOIB=yCONFIG_INFINIBAND_IPOIB_CM=yCONFIG_INFINIBAND_IPOIB_DEBUG=y
# CONFIG_INFINIBAND_IPOIB_DEBUG_DATA is not set
# CONFIG_INFINIBAND_SRP is not setCONFIG_INFINIBAND_ISER=y
# CONFIG_EDAC is not setCONFIG_RTC_LIB=yCONFIG_RTC_CLASS=y
# CONFIG_RTC_HCTOSYS is not set
# CONFIG_RTC_DEBUG is not set
#
# RTC interfaces
#
# CONFIG_RTC_INTF_SYSFS is not set
# CONFIG_RTC_INTF_PROC is not setCONFIG_RTC_INTF_DEV=yCONFIG_RTC_INTF_DEV_UIE_EMUL=yCONFIG_RTC_DRV_TEST=y
#
# I2C RTC drivers
#
# CONFIG_RTC_DRV_DS1307 is not set
# CONFIG_RTC_DRV_DS1374 is not setCONFIG_RTC_DRV_DS1672=yCONFIG_RTC_DRV_MAX6900=yCONFIG_RTC_DRV_RS5C372=y
# CONFIG_RTC_DRV_ISL1208 is not set
# CONFIG_RTC_DRV_X1205 is not set
# CONFIG_RTC_DRV_PCF8563 is not setCONFIG_RTC_DRV_PCF8583=yCONFIG_RTC_DRV_M41T80=y
# CONFIG_RTC_DRV_M41T80_WDT is not set
#
# SPI RTC drivers
#
#
# Platform RTC drivers
#CONFIG_RTC_DRV_CMOS=yCONFIG_RTC_DRV_DS1553=y
# CONFIG_RTC_DRV_STK17TA8 is not set
# CONFIG_RTC_DRV_DS1742 is not setCONFIG_RTC_DRV_M48T86=yCONFIG_RTC_DRV_M48T59=yCONFIG_RTC_DRV_V3020=y
#
# on-CPU RTC drivers
#CONFIG_DMADEVICES=y
#
# DMA Devices
#
# CONFIG_INTEL_IOATDMA is not setCONFIG_AUXDISPLAY=y
# CONFIG_VIRTUALIZATION is not set
#
# Userspace I/O
#
# CONFIG_UIO is not set
#
# Firmware Drivers
#
# CONFIG_EDD is not set
# CONFIG_DELL_RBU is not set
# CONFIG_DCDBAS is not setCONFIG_DMIID=y
#
# File systems
#
# CONFIG_EXT2_FS is not setCONFIG_EXT3_FS=yCONFIG_EXT3_FS_XATTR=yCONFIG_EXT3_FS_POSIX_ACL=yCONFIG_EXT3_FS_SECURITY=y
# CONFIG_EXT4DEV_FS is not setCONFIG_JBD=yCONFIG_JBD_DEBUG=yCONFIG_FS_MBCACHE=y
# CONFIG_REISERFS_FS is not setCONFIG_JFS_FS=y
# CONFIG_JFS_POSIX_ACL is not setCONFIG_JFS_SECURITY=y
# CONFIG_JFS_DEBUG is not set
# CONFIG_JFS_STATISTICS is not setCONFIG_FS_POSIX_ACL=yCONFIG_XFS_FS=y
# CONFIG_XFS_QUOTA is not setCONFIG_XFS_SECURITY=yCONFIG_XFS_POSIX_ACL=yCONFIG_XFS_RT=yCONFIG_GFS2_FS=yCONFIG_GFS2_FS_LOCKING_NOLOCK=yCONFIG_GFS2_FS_LOCKING_DLM=y
# CONFIG_OCFS2_FS is not setCONFIG_MINIX_FS=yCONFIG_ROMFS_FS=y
# CONFIG_INOTIFY is not set
# CONFIG_QUOTA is not setCONFIG_DNOTIFY=yCONFIG_AUTOFS_FS=yCONFIG_AUTOFS4_FS=yCONFIG_FUSE_FS=yCONFIG_GENERIC_ACL=y
#
# CD-ROM/DVD Filesystems
#
# CONFIG_ISO9660_FS is not setCONFIG_UDF_FS=yCONFIG_UDF_NLS=y
#
# DOS/FAT/NT Filesystems
#CONFIG_FAT_FS=yCONFIG_MSDOS_FS=yCONFIG_VFAT_FS=yCONFIG_FAT_DEFAULT_CODEPAGE=437CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1"
# CONFIG_NTFS_FS is not set
#
# Pseudo filesystems
#CONFIG_PROC_FS=yCONFIG_PROC_KCORE=yCONFIG_PROC_SYSCTL=yCONFIG_SYSFS=yCONFIG_TMPFS=yCONFIG_TMPFS_POSIX_ACL=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not setCONFIG_CONFIGFS_FS=y
#
# Miscellaneous filesystems
#CONFIG_ADFS_FS=y
# CONFIG_ADFS_FS_RW is not setCONFIG_AFFS_FS=yCONFIG_ECRYPT_FS=yCONFIG_HFS_FS=yCONFIG_HFSPLUS_FS=y
# CONFIG_BEFS_FS is not setCONFIG_BFS_FS=y
# CONFIG_EFS_FS is not set
# CONFIG_CRAMFS is not set
# CONFIG_VXFS_FS is not setCONFIG_HPFS_FS=y
# CONFIG_QNX4FS_FS is not set
# CONFIG_SYSV_FS is not setCONFIG_UFS_FS=yCONFIG_UFS_FS_WRITE=yCONFIG_UFS_DEBUG=yCONFIG_NETWORK_FILESYSTEMS=y
# CONFIG_NFS_FS is not setCONFIG_NFSD=y
# CONFIG_NFSD_V3 is not set
# CONFIG_NFSD_TCP is not setCONFIG_LOCKD=yCONFIG_EXPORTFS=yCONFIG_NFS_COMMON=yCONFIG_SUNRPC=yCONFIG_SUNRPC_GSS=yCONFIG_SUNRPC_XPRT_RDMA=y
# CONFIG_SUNRPC_BIND34 is not set
# CONFIG_RPCSEC_GSS_KRB5 is not setCONFIG_RPCSEC_GSS_SPKM3=y
# CONFIG_SMB_FS is not setCONFIG_CIFS=y
# CONFIG_CIFS_STATS is not set
# CONFIG_CIFS_WEAK_PW_HASH is not set
# CONFIG_CIFS_XATTR is not set
# CONFIG_CIFS_DEBUG2 is not setCONFIG_CIFS_EXPERIMENTAL=y
# CONFIG_CIFS_UPCALL is not set
# CONFIG_NCP_FS is not setCONFIG_CODA_FS=y
# CONFIG_CODA_FS_OLD_API is not setCONFIG_AFS_FS=y
# CONFIG_AFS_DEBUG is not set
# CONFIG_9P_FS is not set
#
# Partition Types
#CONFIG_PARTITION_ADVANCED=yCONFIG_ACORN_PARTITION=y
# CONFIG_ACORN_PARTITION_CUMANA is not set
# CONFIG_ACORN_PARTITION_EESOX is not setCONFIG_ACORN_PARTITION_ICS=y
# CONFIG_ACORN_PARTITION_ADFS is not set
# CONFIG_ACORN_PARTITION_POWERTEC is not setCONFIG_ACORN_PARTITION_RISCIX=yCONFIG_OSF_PARTITION=yCONFIG_AMIGA_PARTITION=yCONFIG_ATARI_PARTITION=yCONFIG_MAC_PARTITION=yCONFIG_MSDOS_PARTITION=yCONFIG_BSD_DISKLABEL=yCONFIG_MINIX_SUBPARTITION=y
# CONFIG_SOLARIS_X86_PARTITION is not setCONFIG_UNIXWARE_DISKLABEL=y
# CONFIG_LDM_PARTITION is not set
# CONFIG_SGI_PARTITION is not setCONFIG_ULTRIX_PARTITION=y
# CONFIG_SUN_PARTITION is not set
# CONFIG_KARMA_PARTITION is not set
# CONFIG_EFI_PARTITION is not set
# CONFIG_SYSV68_PARTITION is not setCONFIG_NLS=yCONFIG_NLS_DEFAULT="iso8859-1"
# CONFIG_NLS_CODEPAGE_437 is not setCONFIG_NLS_CODEPAGE_737=yCONFIG_NLS_CODEPAGE_775=yCONFIG_NLS_CODEPAGE_850=y
# CONFIG_NLS_CODEPAGE_852 is not setCONFIG_NLS_CODEPAGE_855=yCONFIG_NLS_CODEPAGE_857=y
# CONFIG_NLS_CODEPAGE_860 is not set
# CONFIG_NLS_CODEPAGE_861 is not set
# CONFIG_NLS_CODEPAGE_862 is not set
# CONFIG_NLS_CODEPAGE_863 is not setCONFIG_NLS_CODEPAGE_864=y
# CONFIG_NLS_CODEPAGE_865 is not set
# CONFIG_NLS_CODEPAGE_866 is not set
# CONFIG_NLS_CODEPAGE_869 is not set
# CONFIG_NLS_CODEPAGE_936 is not set
# CONFIG_NLS_CODEPAGE_950 is not setCONFIG_NLS_CODEPAGE_932=y
# CONFIG_NLS_CODEPAGE_949 is not set
# CONFIG_NLS_CODEPAGE_874 is not set
# CONFIG_NLS_ISO8859_8 is not set
# CONFIG_NLS_CODEPAGE_1250 is not set
# CONFIG_NLS_CODEPAGE_1251 is not setCONFIG_NLS_ASCII=y
# CONFIG_NLS_ISO8859_1 is not setCONFIG_NLS_ISO8859_2=yCONFIG_NLS_ISO8859_3=y
# CONFIG_NLS_ISO8859_4 is not set
# CONFIG_NLS_ISO8859_5 is not set
# CONFIG_NLS_ISO8859_6 is not setCONFIG_NLS_ISO8859_7=yCONFIG_NLS_ISO8859_9=y
# CONFIG_NLS_ISO8859_13 is not setCONFIG_NLS_ISO8859_14=yCONFIG_NLS_ISO8859_15=yCONFIG_NLS_KOI8_R=y
# CONFIG_NLS_KOI8_U is not setCONFIG_NLS_UTF8=yCONFIG_DLM=y
# CONFIG_DLM_DEBUG is not setCONFIG_INSTRUMENTATION=yCONFIG_PROFILING=yCONFIG_OPROFILE=yCONFIG_MARKERS=y
#
# Kernel hacking
#CONFIG_TRACE_IRQFLAGS_SUPPORT=y
# CONFIG_PRINTK_TIME is not setCONFIG_ENABLE_WARN_DEPRECATED=yCONFIG_ENABLE_MUST_CHECK=yCONFIG_MAGIC_SYSRQ=yCONFIG_UNUSED_SYMBOLS=yCONFIG_DEBUG_FS=yCONFIG_HEADERS_CHECK=yCONFIG_DEBUG_KERNEL=y
# CONFIG_DEBUG_SHIRQ is not set
# CONFIG_DETECT_SOFTLOCKUP is not setCONFIG_SCHED_DEBUG=yCONFIG_SCHEDSTATS=y
# CONFIG_TIMER_STATS is not setCONFIG_SLUB_DEBUG_ON=y
# CONFIG_DEBUG_RT_MUTEXES is not set
# CONFIG_RT_MUTEX_TESTER is not setCONFIG_DEBUG_SPINLOCK=yCONFIG_DEBUG_MUTEXES=yCONFIG_DEBUG_LOCK_ALLOC=y
# CONFIG_PROVE_LOCKING is not setCONFIG_LOCKDEP=y
# CONFIG_LOCK_STAT is not set
# CONFIG_DEBUG_LOCKDEP is not set
# CONFIG_DEBUG_SPINLOCK_SLEEP is not setCONFIG_DEBUG_LOCKING_API_SELFTESTS=yCONFIG_STACKTRACE=y
# CONFIG_DEBUG_KOBJECT is not setCONFIG_DEBUG_BUGVERBOSE=y
# CONFIG_DEBUG_INFO is not set
# CONFIG_DEBUG_VM is not set
# CONFIG_DEBUG_LIST is not set
# CONFIG_DEBUG_SG is not setCONFIG_FRAME_POINTER=y
# CONFIG_FORCED_INLINING is not setCONFIG_BOOT_PRINTK_DELAY=y
# CONFIG_BACKTRACE_SELF_TEST is not set
# CONFIG_FAULT_INJECTION is not setCONFIG_PROVIDE_OHCI1394_DMA_INIT=y
# CONFIG_SAMPLES is not set
# CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set
# CONFIG_UNWIND_INFO is not set
# CONFIG_KGDB is not setCONFIG_EARLY_PRINTK=yCONFIG_DEBUG_STACKOVERFLOW=y
# CONFIG_DEBUG_STACK_USAGE is not setCONFIG_DEBUG_PAGEALLOC=y
# CONFIG_DEBUG_RODATA is not set
# CONFIG_4KSTACKS is not setCONFIG_X86_FIND_SMP_CONFIG=yCONFIG_X86_MPPARSE=yCONFIG_DOUBLEFAULT=yCONFIG_IO_DELAY_TYPE_0X80=0CONFIG_IO_DELAY_TYPE_0XED=1CONFIG_IO_DELAY_TYPE_UDELAY=2CONFIG_IO_DELAY_TYPE_NONE=3CONFIG_IO_DELAY_0X80=y
# CONFIG_IO_DELAY_0XED is not set
# CONFIG_IO_DELAY_UDELAY is not set
# CONFIG_IO_DELAY_NONE is not setCONFIG_DEFAULT_IO_DELAY_TYPE=0
# CONFIG_DEBUG_BOOT_PARAMS is not setCONFIG_CPA_DEBUG=y
#
# Security options
#CONFIG_KEYS=yCONFIG_KEYS_DEBUG_PROC_KEYS=yCONFIG_SECURITY=y
# CONFIG_SECURITY_NETWORK is not setCONFIG_SECURITY_CAPABILITIES=yCONFIG_SECURITY_FILE_CAPABILITIES=y
# CONFIG_SECURITY_ROOTPLUG is not setCONFIG_CRYPTO=yCONFIG_CRYPTO_ALGAPI=yCONFIG_CRYPTO_BLKCIPHER=yCONFIG_CRYPTO_HASH=yCONFIG_CRYPTO_MANAGER=yCONFIG_CRYPTO_HMAC=yCONFIG_CRYPTO_XCBC=y
# CONFIG_CRYPTO_NULL is not set
# CONFIG_CRYPTO_MD4 is not setCONFIG_CRYPTO_MD5=yCONFIG_CRYPTO_SHA1=yCONFIG_CRYPTO_SHA256=yCONFIG_CRYPTO_SHA512=yCONFIG_CRYPTO_WP512=y
# CONFIG_CRYPTO_TGR192 is not setCONFIG_CRYPTO_GF128MUL=yCONFIG_CRYPTO_ECB=yCONFIG_CRYPTO_CBC=yCONFIG_CRYPTO_PCBC=y
# CONFIG_CRYPTO_LRW is not setCONFIG_CRYPTO_XTS=y
# CONFIG_CRYPTO_CRYPTD is not setCONFIG_CRYPTO_DES=yCONFIG_CRYPTO_FCRYPT=y
# CONFIG_CRYPTO_BLOWFISH is not set
# CONFIG_CRYPTO_TWOFISH is not set
# CONFIG_CRYPTO_TWOFISH_586 is not set
# CONFIG_CRYPTO_SERPENT is not setCONFIG_CRYPTO_AES=yCONFIG_CRYPTO_AES_586=yCONFIG_CRYPTO_CAST5=y
# CONFIG_CRYPTO_CAST6 is not set
# CONFIG_CRYPTO_TEA is not setCONFIG_CRYPTO_ARC4=y
# CONFIG_CRYPTO_KHAZAD is not setCONFIG_CRYPTO_ANUBIS=y
# CONFIG_CRYPTO_SEED is not setCONFIG_CRYPTO_DEFLATE=y
# CONFIG_CRYPTO_MICHAEL_MIC is not setCONFIG_CRYPTO_CRC32C=y
# CONFIG_CRYPTO_CAMELLIA is not set
# CONFIG_CRYPTO_AUTHENC is not setCONFIG_CRYPTO_HW=yCONFIG_CRYPTO_DEV_PADLOCK=y
# CONFIG_CRYPTO_DEV_PADLOCK_AES is not setCONFIG_CRYPTO_DEV_PADLOCK_SHA=y
# CONFIG_CRYPTO_DEV_GEODE is not set
#
# Library routines
#CONFIG_BITREVERSE=yCONFIG_CRC_CCITT=y
# CONFIG_CRC16 is not setCONFIG_CRC_ITU_T=yCONFIG_CRC32=y
# CONFIG_CRC7 is not setCONFIG_LIBCRC32C=yCONFIG_ZLIB_INFLATE=yCONFIG_ZLIB_DEFLATE=yCONFIG_TEXTSEARCH=yCONFIG_TEXTSEARCH_KMP=yCONFIG_TEXTSEARCH_BM=yCONFIG_TEXTSEARCH_FSM=yCONFIG_PLIST=yCONFIG_HAS_IOMEM=yCONFIG_HAS_IOPORT=yCONFIG_HAS_DMA=yCONFIG_CHECK_SIGNATURE=y
Linux version 2.6.24-rc8 (mingo@dione) (gcc version 4.2.2) #15 SMP Tue Jan 22 17:43:21 CET 2008 BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f800 (usable)
BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 000000003fff0000 (usable)
BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS)
BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved)
console [earlyser0] enabled
Warning only 896MB will be used.
Use a HIGHMEM enabled kernel.
896MB LOWMEM available.
Scan SMP from c0000000 for 1024 bytes.
Scan SMP from c009fc00 for 1024 bytes.
Scan SMP from c00f0000 for 65536 bytes.
found SMP MP-table at [c00f5680] 000f5680
Entering add_active_range(0, 0, 229376) 0 entries of 256 used
Zone PFN ranges:
DMA 0 -> 4096
Normal 4096 -> 229376
Movable zone start PFN for each node
early_node_map[1] active PFN ranges
0: 0 -> 229376
On node 0 totalpages: 229376
DMA zone: 52 pages used for memmap
DMA zone: 0 pages reserved
DMA zone: 4044 pages, LIFO batch:0
Normal zone: 2860 pages used for memmap
Normal zone: 222420 pages, LIFO batch:31
Movable zone: 0 pages used for memmap
DMI 2.3 present.
ACPI: RSDP 000F76F0, 0014 (r0 Nvidia)
ACPI: RSDT 3FFF3040, 0034 (r1 Nvidia AWRDACPI 42302E31 AWRD 0)
ACPI: FACP 3FFF30C0, 0074 (r1 Nvidia AWRDACPI 42302E31 AWRD 0)
ACPI: DSDT 3FFF3180, 6264 (r1 NVIDIA AWRDACPI 1000 MSFT 100000E)
ACPI: FACS 3FFF0000, 0040
ACPI: SRAT 3FFF9500, 00A0 (r1 AMD HAMMER 1 AMD 1)
ACPI: MCFG 3FFF9600, 003C (r1 Nvidia AWRDACPI 42302E31 AWRD 0)
ACPI: APIC 3FFF9440, 007C (r1 Nvidia AWRDACPI 42302E31 AWRD 0)
Nvidia board detected. Ignoring ACPI timer override.
If you got timer trouble try acpi_use_timer_override
ACPI: PM-Timer IO Port: 0x4008
Intel MultiProcessor Specification v1.4
Virtual Wire compatibility mode.
OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000
Processor #0 15:3 APIC version 17
Processor #1 15:3 APIC version 17
I/O APIC #2 Version 17 at 0xFEC00000.
Enabling APIC mode: Flat. Using 1 I/O APICs
Processors: 2
Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000)
Built 1 zonelists in Zone order, mobility grouping on. Total pages: 226464
Kernel command line: root=/dev/sda1 console=ttyS0,115200 console=tty earlyprintk=serial,ttyS0,115200 3 profile=0 debug initcall_debug enforcing=0 apic=verbose sysrq_always_enabled ignore_loglevel selinux=0 nosmp highres=0 nolapic idle=mwait nopat kernel profiling enabled (shift: 0)
debug: sysrq always enabled.
debug: ignoring loglevel setting.
mapped APIC to ffffb000 (fee00000)
mapped IOAPIC to ffffa000 (fec00000)
Enabling fast FPU save and restore... done.
Enabling unmasked SIMD FPU exception support... done.
Initializing CPU#0
PID hash table entries: 4096 (order: 12, 16384 bytes)
Detected 2160.224 MHz processor.
spurious 8259A interrupt: IRQ7.
Console: colour VGA+ 80x25
console handover: boot [earlyser0] -> real [tty0]
console [ttyS0] enabled
Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar
... MAX_LOCKDEP_SUBCLASSES: 8
... MAX_LOCK_DEPTH: 30
... MAX_LOCKDEP_KEYS: 2048
... CLASSHASH_SIZE: 1024
... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192
memory used by lock dependency info: 992 kB
per task-struct memory footprint: 1200 bytes
------------------------
| Locking API testsuite:
----------------------------------------------------------------------------
| spin |wlock |rlock |mutex | wsem | rsem |
--------------------------------------------------------------------------
A-A deadlock:failed|failed| ok |failed|failed|failed|
A-B-B-A deadlock:failed|failed| ok |failed|failed|failed|
A-B-B-C-C-A deadlock:failed|failed| ok |failed|failed|failed|
A-B-C-A-B-C deadlock:failed|failed| ok |failed|failed|failed|
A-B-B-C-C-D-D-A deadlock:failed|failed| ok |failed|failed|failed|
A-B-C-D-B-D-D-A deadlock:failed|failed| ok |failed|failed|failed|
A-B-C-D-B-C-D-A deadlock:failed|failed| ok |failed|failed|failed|
double unlock: ok | ok |failed| ok |failed|failed|
initialize held:failed|failed|failed|failed|failed|failed|
bad unlock order: ok | ok | ok | ok | ok | ok |
--------------------------------------------------------------------------
recursive read-lock: | ok | |failed|
recursive read-lock #2: | ok | |failed|
mixed read-write-lock: |failed| |failed|
mixed write-read-lock: |failed| |failed|
--------------------------------------------------------------------------
hard-irqs-on + irq-safe-A/12:failed|failed| ok |
soft-irqs-on + irq-safe-A/12:failed|failed| ok |
hard-irqs-on + irq-safe-A/21:failed|failed| ok |
soft-irqs-on + irq-safe-A/21:failed|failed| ok |
sirq-safe-A => hirqs-on/12:failed|failed| ok |
sirq-safe-A => hirqs-on/21:failed|failed| ok |
hard-safe-A + irqs-on/12:failed|failed| ok |
soft-safe-A + irqs-on/12:failed|failed| ok |
hard-safe-A + irqs-on/21:failed|failed| ok |
soft-safe-A + irqs-on/21:failed|failed| ok |
hard-safe-A + unsafe-B #1/123:failed|failed| ok |
soft-safe-A + unsafe-B #1/123:failed|failed| ok |
hard-safe-A + unsafe-B #1/132:failed|failed| ok |
soft-safe-A + unsafe-B #1/132:failed|failed| ok |
hard-safe-A + unsafe-B #1/213:failed|failed| ok |
soft-safe-A + unsafe-B #1/213:failed|failed| ok |
hard-safe-A + unsafe-B #1/231:failed|failed| ok |
soft-safe-A + unsafe-B #1/231:failed|failed| ok |
hard-safe-A + unsafe-B #1/312:failed|failed| ok |
soft-safe-A + unsafe-B #1/312:failed|failed| ok |
hard-safe-A + unsafe-B #1/321:failed|failed| ok |
soft-safe-A + unsafe-B #1/321:failed|failed| ok |
hard-safe-A + unsafe-B #2/123:failed|failed| ok |
soft-safe-A + unsafe-B #2/123:failed|failed| ok |
hard-safe-A + unsafe-B #2/132:failed|failed| ok |
soft-safe-A + unsafe-B #2/132:failed|failed| ok |
hard-safe-A + unsafe-B #2/213:failed|failed| ok |
soft-safe-A + unsafe-B #2/213:failed|failed| ok |
hard-safe-A + unsafe-B #2/231:failed|failed| ok |
soft-safe-A + unsafe-B #2/231:failed|failed| ok |
hard-safe-A + unsafe-B #2/312:failed|failed| ok |
soft-safe-A + unsafe-B #2/312:failed|failed| ok |
hard-safe-A + unsafe-B #2/321:failed|failed| ok |
soft-safe-A + unsafe-B #2/321:failed|failed| ok |
hard-irq lock-inversion/123:failed|failed| ok |
soft-irq lock-inversion/123:failed|failed| ok |
hard-irq lock-inversion/132:failed|failed| ok |
soft-irq lock-inversion/132:failed|failed| ok |
hard-irq lock-inversion/213:failed|failed| ok |
soft-irq lock-inversion/213:failed|failed| ok |
hard-irq lock-inversion/231:failed|failed| ok |
soft-irq lock-inversion/231:failed|failed| ok |
hard-irq lock-inversion/312:failed|failed| ok |
soft-irq lock-inversion/312:failed|failed| ok |
hard-irq lock-inversion/321:failed|failed| ok |
soft-irq lock-inversion/321:failed|failed| ok |
hard-irq read-recursion/123: ok |
soft-irq read-recursion/123: ok |
hard-irq read-recursion/132: ok |
soft-irq read-recursion/132: ok |
hard-irq read-recursion/213: ok |
soft-irq read-recursion/213: ok |
hard-irq read-recursion/231: ok |
soft-irq read-recursion/231: ok |
hard-irq read-recursion/312: ok |
soft-irq read-recursion/312: ok |
hard-irq read-recursion/321: ok |
soft-irq read-recursion/321: ok |--------------------------------------------------------
142 out of 218 testcases failed, as expected. |
----------------------------------------------------
Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes)
------------[ cut here ]------------ kernel BUG at arch/x86/mm/pageattr_32.c:327!
invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC
Pid: 0, comm: swapper Not tainted (2.6.24-rc8 #15)
EIP: 0060:[<c0116a3f>] EFLAGS: 00010297 CPU: 0
EIP is at kernel_map_pages+0x52/0xb3
EAX: c0a6fc00 EBX: c0003000 ECX: c0a6fc00 EDX: c0a6fc00
ESI: c100109c EDI: 00000000 EBP: c0a19f34 ESP: c0a19f1c
DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068
Process swapper (pid: 0, ti=c0a18000 task=c0902390 task.ti=c0a18000)
Stack: 00000000 00000001 00000002 c100109c 00000000 ffffffff c0a19f50 c014a77e
00000000 c090ba10 c100109c 00000000 00000003 c0a19f58 c014a844 c0a19f60
c014adea c0a19f70 c0a2f8b6 fffffff8 c100109c c0a19fa4 c0a2e2f5 00000005
Call Trace:
[<c014a77e>] ? free_hot_cold_page+0xb5/0x13c
[<c014a844>] ? free_hot_page+0xa/0xc
[<c014adea>] ? __free_pages+0x1b/0x26
[<c0a2f8b6>] ? __free_pages_bootmem+0x54/0x58
[<c0a2e2f5>] ? free_all_bootmem_core+0xde/0x154
[<c0a2e378>] ? free_all_bootmem+0xd/0xf
[<c0a2b2d1>] ? mem_init+0x26/0x21e
[<c0a21862>] ? start_kernel+0x273/0x2f9
=======================
Code: 00 c0 85 c9 74 04 31 ff eb 73 8b 55 ec c1 e2 0c 89 d8 e8 67 51 02 00 eb ed 8d 55 f0 89 d8 e8 e9 fa ff ff 89 c2 83 7d f0 03 74 04 <0f> 0b eb fe 83 7d e8 00 74 24 89 f0 2b 05 24 11 c4 c0 c1 f8 02
EIP: [<c0116a3f>] kernel_map_pages+0x52/0xb3 SS:ESP 0068:c0a19f1c
---[ end trace ca143223eefdc828 ]---
Kernel panic - not syncing: Attempted to kill the idle task!PATCH 1/1 x86_32: trim memory by updating e820 v3
[PATCH] x86_32: trim memory by updating e820 v3
when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for x86_64
here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early
need Justine to test with his special system with bug bios.
arch/x86/kernel/cpu/common.c +29 -1
@@ -278,6 +278,33 @@ void __init cpu_detect(struct cpuinfo_x8 c->x86_cache_alignment = ((misc >>8 ) &0xff ) *8 ; } } +static void __cpuinit early_get_cap (struct cpuinfo_x86 *c) +{ +u32 tfms, xlvl; +int ebx; + +memset (&c->x86_capability,0 ,sizeof c->x86_capability); +if (have_cpuid_p ()) { +/* Intel-defined flags: level 0x00000001 */ +if (c->cpuid_level >=0x00000001 ) { +u32 capability, excap; +cpuid (0x00000001 , &tfms, &ebx, &excap, &capability); + c->x86_capability[0 ] = capability; + c->x86_capability[4 ] = excap; + } + +/* AMD-defined flags: level 0x80000001 */ + xlvl =cpuid_eax (0x80000000 ); +if ((xlvl &0xffff0000 ) ==0x80000000 ) { +if (xlvl >=0x80000001 ) { + c->x86_capability[1 ] =cpuid_edx (0x80000001 ); + c->x86_capability[6 ] =cpuid_ecx (0x80000001 ); + } + } + + } + +}/* Do minimum CPU detection early. Fields really needed: vendor, cpuid_level, family, model, mask, cache alignment.
@@ -306,6 +333,8 @@ static void __init early_cpu_detect(voidearly_init_intel (c);break ; } + +early_get_cap (c); }static void __cpuinit generic_identify (struct cpuinfo_x86 * c)
@@ -485,7 +514,6 @@ void __init identify_boot_cpu(void)identify_cpu (&boot_cpu_data);sysenter_setup ();enable_sep_cpu (); -mtrr_bp_init (); }void __cpuinit identify_secondary_cpu (struct cpuinfo_x86 *c)
arch/x86/kernel/setup_32.c +6 -0
@@ -49,6 +49,7 @@#include <video/edid.h> +#include <asm/mtrr.h> #include <asm/apic.h> #include <asm/e820.h> #include <asm/mpspec.h>
@@ -762,6 +763,11 @@ void __init setup_arch(char **cmdline_p) max_low_pfn =setup_memory (); +/* update e820 for memory not covered by WB MTRRs */ +mtrr_bp_init (); +if (mtrr_trim_uncached_memory (max_pfn)) + max_low_pfn =setup_memory (); +#ifdef CONFIG_VMI /* * Must be after max_low_pfn is determined, and before kernel
arch/x86/kernel/cpu/mtrr/main.c +0 -2
@@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; -#ifdef CONFIG_X86_64 static int disable_mtrr_trim;static int __init disable_mtrr_trim_setup (char *str)
@@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(unsreturn 0 ; } -#endif /** * mtrr_bp_init - initialize mtrrs on the boot CPU
Documentation/kernel-parameters.txt +1 -1
@@ -575,7 +575,7 @@ and is between 256 and 4096 characters. See drivers/char/README.epca and Documentation/digiepca.txt. - disable_mtrr_trim [X86-64, Intel only] + disable_mtrr_trim [X86, Intel and AMD only] By default the kernel will trim any uncacheable memory out of your available memory pool based on MTRR settings. This parameter disables that behavior,
arch/x86/kernel/e820_32.c +11 -0
@@ -749,3 +749,14 @@ static int __init parse_memmap(char *argreturn 0 ; }early_param ("memmap" , parse_memmap); +void __init update_e820 (void ) +{ +u8 nr_map; + + nr_map = e820.nr_map; +if (sanitize_e820_map (e820.map, &nr_map)) +return ; + e820.nr_map = nr_map; +printk (KERN_INFO "modified physical RAM map:\n" ); +print_memory_map ("modified" ); +}
include/asm-x86/e820_32.h +3 -0
@@ -19,12 +19,15 @@#ifndef __ASSEMBLY__extern struct e820map e820; +extern void update_e820 (void );extern int e820_all_mapped (unsigned long start,unsigned long end,unsigned type);extern int e820_any_mapped (u64 start,u64 end,unsigned type);extern void find_max_pfn (void );extern void register_bootmem_low_pages (unsigned long max_low_pfn); +extern void add_memory_region (unsigned long long start, +unsigned long long size,int type);extern void e820_register_memory (void );extern void limit_regions (unsigned long long size);extern void print_memory_map (char *who);
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> wrote:
[PATCH]
x86_32: trim memory by updating e820 v3when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_get_capand use it inearly_cpu_detect, and movemtrr_bp_initearlyneed Justine to test with his special system with bug bios.
Signed-off-by Yinghai Lu <[email protected]>
Speaking of mtrr and e820....
Could someone please take a peek at
http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?
For some reason we seem to have turned this:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)
into this:
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
which screws up the X server's attempt to map the video memory at 0xd0000000.
Thanks.
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> wrote:
[PATCH]
x86_32: trim memory by updating e820 v3when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_get_capand use it inearly_cpu_detect, and movemtrr_bp_initearlyneed Justine to test with his special system with bug bios.
Signed-off-by Yinghai Lu <[email protected]>Speaking of mtrr and e820....
Could someone please take a peek at
http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?For some reason we seem to have turned this:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)into this:
Quoted 8 lines
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1which screws up the X server's attempt to map the video memory at
0xd0000000.
I see that on my box with ASUS P5E-VM DO and 4G RAM.
It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.
I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.
Also I get the mtrr type mismatch message on 32 and 64 bit kernels.
...
[ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable)
...
cat /proc/mtrr :
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1
dmesg is saying :
..
[ 24.012694] [drm] Initialized i915 1.6.0 20060119 on minor 0 [ 24.175500] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining [ 24.423740] set status page addr 0x00033000
..
from Xorg log :
...
(WW) intel(0): Failed to set up write-combining range (0xd0000000,0x10000000) (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000
...
Regards,
Gabriel
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 83 lines · Gabriel C
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> wrote:
[PATCH]
x86_32: trim memory by updating e820 v3when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_get_capand use it inearly_cpu_detect, and movemtrr_bp_initearlyneed Justine to test with his special system with bug bios.
Signed-off-by Yinghai Lu <[email protected]>Speaking of mtrr and e820....
Could someone please take a peek at
http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?For some reason we seem to have turned this:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)into this:
Quoted 8 lines
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1which screws up the X server's attempt to map the video memory at
0xd0000000.I see that on my box with ASUS P5E-VM DO and 4G RAM.
It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.
Also I get the mtrr type mismatch message on 32 and 64 bit kernels.
...
[ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) ...cat
/proc/mtrr:reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1
Quoted 7 lines
dmesg is saying :
..
[ 24.012694] [drm] Initialized i915 1.6.0 20060119 on minor 0 [ 24.175500] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining [ 24.423740] set status page addr 0x00033000
another continuous MTRR mapping.
several months ago, we were talking about modifying MTRR. but Eric said that is not safe because acpi and smi...
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 6 lines · Yinghai Lu
On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <[email protected]> wrote:
another continuous MTRR mapping.
several months ago, we were talking about modifying MTRR. but Eric said that is not safe because acpi and smi...
I think it was Andi who spotted that originally, and yes I do think it is a pretty horrific failure mode. Reprogramming the MTRRs requires full knowledge of the hardware and what is going on that we don't always have. PAT support has just been merged, and using that only requires knowledge about the region whose attributes we intend to change.
So lets concentrate on PAT to solve contiguous MTRR region problems.
We can upgrade UC to WC with pat. As well as demote WB to UC or WC. So for those regions we know about we should be in good shape.
In a slightly related vein. Trimming the memory we consider usable by looking at MTRRs and if a region is not WB not considering it RAM sounds like a very reasonable work around for one class of BIOS bugs.
Eric
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 16 lines · Eric W. Biederman
Quoted 7 lines · Yinghai Lu
On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <[email protected]> wrote:
another continuous MTRR mapping.
several months ago, we were talking about modifying MTRR. but Eric said that is not safe because acpi and smi...
I think it was Andi who spotted that originally, and yes I do think it is a pretty horrific failure mode. Reprogramming the MTRRs requires full knowledge of the hardware and what is going on that we don't always have. PAT support has just been merged, and using that only requires knowledge about the region whose attributes we intend to change.
Quoted 8 lines
So lets concentrate on PAT to solve contiguous MTRR region problems.
We can upgrade UC to WC with pat. As well as demote WB to UC or WC. So for those regions we know about we should be in good shape.
In a slightly related vein. Trimming the memory we consider usable by looking at MTRRs and if a region is not WB not considering it RAM sounds like a very reasonable work around for one class of BIOS bugs.
yeah, i will look at to loop the ram region array instead of checking highest_pfn only...
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
In reply to Eric W. BiedermanQuoted 4 lines · Eric W. Biederman
So lets concentrate on PAT to solve contiguous MTRR region problems.
We can upgrade UC to WC with pat. As well as demote WB to UC or WC. So for those regions we know about we should be in good shape.
sure, but whatever we do now in the sysfs API space, it will hit distros only in a year, relistically, because Xorg also has to adopt to it. The workaround from Yinghai looks reasonably configurable - if we mess up (say an SMM comes in while we fiddle with the MTRRs) we'll likely get a lockup right then, during bootup, so it wont be hard to realize what went wrong. In that sense it's in fact safer to do it during early init than let the user do it via some script, because the window is smaller, etc.
we still default to the safe mode of course and dont touch MTRRs, but for note the various configuration options that are available to distros and users.
Ingo
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 16 lines · Ingo Molnar
Quoted 4 lines · Eric W. Biederman
So lets concentrate on PAT to solve contiguous MTRR region problems.
We can upgrade UC to WC with pat. As well as demote WB to UC or WC. So for those regions we know about we should be in good shape.
sure, but whatever we do now in the sysfs API space, it will hit distros only in a year, relistically, because Xorg also has to adopt to it. The workaround from Yinghai looks reasonably configurable - if we mess up (say an SMM comes in while we fiddle with the MTRRs) we'll likely get a lockup right then, during bootup, so it wont be hard to realize what went wrong. In that sense it's in fact safer to do it during early init than let the user do it via some script, because the window is smaller, etc.
Quoted 3 lines
we still default to the safe mode of course and dont touch MTRRs, but for note the various configuration options that are available to distros and users.
The potential problem isn't while we reprogram the MTRRs, the potential problem is mapping the SMM area uncachable. In which case we will make each SMM interrupt drastically slower. Which can have all kinds of unpleasant side effects.
If we really can mess up SMM mode that way we have a really nasty interaction that is horrible to debug, or recognize.
Further the opportunity for this kind of fixup is small. Newer AMD systems don't need it as they have an extra way of specifying memory about 4G as WB. Systems with just the MTRRs can only use this when they have right around 4GB because with more memory there are not enough MTRRs to leave them non-overlapping and still mark all of memory WB.
Eric
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 19 lines · Eric W. Biederman
Quoted 16 lines · Ingo Molnar
Quoted 4 lines · Eric W. Biederman
So lets concentrate on PAT to solve contiguous MTRR region problems.
We can upgrade UC to WC with pat. As well as demote WB to UC or WC. So for those regions we know about we should be in good shape.
sure, but whatever we do now in the sysfs API space, it will hit distros only in a year, relistically, because Xorg also has to adopt to it. The workaround from Yinghai looks reasonably configurable - if we mess up (say an SMM comes in while we fiddle with the MTRRs) we'll likely get a lockup right then, during bootup, so it wont be hard to realize what went wrong. In that sense it's in fact safer to do it during early init than let the user do it via some script, because the window is smaller, etc.
Quoted 8 lines
Quoted 3 lines
we still default to the safe mode of course and dont touch MTRRs, but for note the various configuration options that are available to distros and users.
The potential problem isn't while we reprogram the MTRRs, the potential problem is mapping the SMM area uncachable. In which case we will make each SMM interrupt drastically slower. Which can have all kinds of unpleasant side effects.
and ACPI area too.
that only try to make the continuous to discrete layout. and still try to cover all that is (WBs - UC) directly with WB.
only thing is that could run out of MTRR..., and mtrr_gran_size is used to avoid that.
then some RAM that is less than mtrr_gran_size could be dumped. so mtrr_gran_size could do sth.
anyway this patch only can meet one end.
for example Mika Fischer's system doesn't need to trim any RAM in MTRR. but for Gabriel's system may need to trim some RAM in MTRR.
current mtrr_gran_size is default to 64M...
may need another patch to loop all mtrr_chunk_size (2g, 1g, ...64M) , mtrr_gran_size (2g, 1g, ...1M) meet
1. leave one or two entry for X server driver
2. lose less cover for RAM in MTRR.
anyway that should be done in BIOS. but ...
Quoted 10 lines
If we really can mess up SMM mode that way we have a really nasty interaction that is horrible to debug, or recognize.
Further the opportunity for this kind of fixup is small. Newer AMD systems don't need it as they have an extra way of specifying memory about 4G as WB. Systems with just the MTRRs can only use this when they have right around 4GB because with more memory there are not enough MTRRs to leave them non-overlapping and still mark all of memory WB.
yes. the patch handle the AMD rev f later with mtrr_tom2. I have one system that give me - ( strange one ?) 0 - 128g WB
4g-512m, 4g wc
after the patch i got
0 - 2048m wb
2048m - 1024m wb
3072m - 3584m wb
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 6 lines · Yinghai Lu
Quoted 4 lines
The potential problem isn't while we reprogram the MTRRs, the potential problem is mapping the SMM area uncachable. In which case we will make each SMM interrupt drastically slower. Which can have all kinds of unpleasant side effects.
and ACPI area too.
True but at least that one is visible.
Quoted 9 lines
that only try to make the continuous to discrete layout. and still try to cover all that is (WBs - UC) directly with WB.
only thing is that could run out of MTRR..., andmtrr_gran_sizeis used to avoid that.
then some RAM that is less thanmtrr_gran_sizecould be dumped. somtrr_gran_sizecould do sth.
anyway this patch only can meet one end.
for example Mika Fischer's system doesn't need to trim any RAM in MTRR. but for Gabriel's system may need to trim some RAM in MTRR.
Right. Ram trimming (changing memory from WB to UC) is the potential problem.
See my other post, in short I think we can address safely address all of the systems where the only problem is the selection of MTRRs by the BIOS.
Then have an option (mtrr_chunk_size) for RAM trimming that is off by default.
It is good to hear that some users and some systems get the benefit without trimming.
Eric
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 23 lines · Eric W. Biederman
Quoted 6 lines · Yinghai Lu
Quoted 4 lines
The potential problem isn't while we reprogram the MTRRs, the potential problem is mapping the SMM area uncachable. In which case we will make each SMM interrupt drastically slower. Which can have all kinds of unpleasant side effects.
and ACPI area too.
True but at least that one is visible.
Quoted 9 lines
that only try to make the continuous to discrete layout. and still try to cover all that is (WBs - UC) directly with WB.
only thing is that could run out of MTRR..., andmtrr_gran_sizeis used to avoid that.
then some RAM that is less thanmtrr_gran_sizecould be dumped. somtrr_gran_sizecould do sth.
anyway this patch only can meet one end.
for example Mika Fischer's system doesn't need to trim any RAM in MTRR. but for Gabriel's system may need to trim some RAM in MTRR.
Quoted 6 lines
Right. Ram trimming (changing memory from WB to UC) is the potential problem.
See my other post, in short I think we can address safely address all of the systems where the only problem is the selection of MTRRs by the BIOS.
BIOS should provide the selection...
Quoted 3 lines
Then have an option (
mtrr_chunk_size) for RAM trimming that is off by default.
Yes. there is CONFIG option and boot command line to enable it.
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 25 lines · Yinghai Lu
Quoted 23 lines · Eric W. Biederman
Quoted 6 lines · Yinghai Lu
Quoted 4 lines
The potential problem isn't while we reprogram the MTRRs, the potential problem is mapping the SMM area uncachable. In which case we will make each SMM interrupt drastically slower. Which can have all kinds of unpleasant side effects.
and ACPI area too.
True but at least that one is visible.
Quoted 9 lines
that only try to make the continuous to discrete layout. and still try to cover all that is (WBs - UC) directly with WB.
only thing is that could run out of MTRR..., andmtrr_gran_sizeis used to avoid that.
then some RAM that is less thanmtrr_gran_sizecould be dumped. somtrr_gran_sizecould do sth.
anyway this patch only can meet one end.
for example Mika Fischer's system doesn't need to trim any RAM in MTRR. but for Gabriel's system may need to trim some RAM in MTRR.
Quoted 8 lines
Quoted 6 lines
Right. Ram trimming (changing memory from WB to UC) is the potential problem.
See my other post, in short I think we can address safely address all of the systems where the only problem is the selection of MTRRs by the BIOS.
BIOS should provide the selection...
The BIOS will setup which areas should be WB in the mtrrs. Having in the linux the ability to change from overlapping mtrrs to discrete mtrrs with BIOS support appears very practical, useful and always safe.
Quoted 4 lines
Quoted 2 lines
Then have an option (
mtrr_chunk_size) for RAM trimming that is off by default.Yes. there is CONFIG option and boot command line to enable it.
However when it is enabled the default chunk size is still 256M. If we did not apply chunk size processing by default so we did not transform any regions from WB to UC by default we could unconditionally enable the code that yields discrete MTRRs.
Then the CONFIG option and the command line option could be made to apply to the dangerous bits that change areas from WB to UC. Which I doubt we will want to have on by default but that can be useful for people who really want to have X go fast and an uncached SMM or ACPI area is not a problem. (ACPI we can handle by just copying the code to a cached area, we can't even discover the SMM area).
Eric
Re: [PATCH] x86_32: trim memory by updating e820 v3
In reply to Gabriel CQuoted 74 lines · Gabriel C
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> wrote:
[PATCH]
x86_32: trim memory by updating e820 v3when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_get_capand use it inearly_cpu_detect, and movemtrr_bp_initearlyneed Justine to test with his special system with bug bios.
Signed-off-by Yinghai Lu <[email protected]>Speaking of mtrr and e820....
Could someone please take a peek at
http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?For some reason we seem to have turned this:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)into this:
Quoted 8 lines
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1which screws up the X server's attempt to map the video memory at
0xd0000000.I see that on my box with ASUS P5E-VM DO and 4G RAM.
It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.
Also I get the mtrr type mismatch message on 32 and 64 bit kernels.
...
[ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) ...cat
/proc/mtrr:
Quoted 7 lines
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1
please try the patch at
http://lkml.org/lkml/2008/4/28/52
with mtrr_chunk_size=1g
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 82 lines · Yinghai Lu
Quoted 73 lines · Gabriel C
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> wrote:
[PATCH]
x86_32: trim memory by updating e820 v3when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_get_capand use it inearly_cpu_detect, and movemtrr_bp_initearlyneed Justine to test with his special system with bug bios.
Signed-off-by Yinghai Lu <[email protected]>Speaking of mtrr and e820....
Could someone please take a peek at
http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?For some reason we seem to have turned this:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)into this:
Quoted 8 lines
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1which screws up the X server's attempt to map the video memory at
0xd0000000.I see that on my box with ASUS P5E-VM DO and 4G RAM.
It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.
Also I get the mtrr type mismatch message on 32 and 64 bit kernels.
...
[ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) ...cat
/proc/mtrr:Quoted 7 lines
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1
Quoted 5 lines
please try the patch at
http://lkml.org/lkml/2008/4/28/52
with mtrr_chunk_size=1g
Hi,
With mtrr_chunk_size=1g my box won't boot :( ( just tested 64bit kernel ).
It does without but I get a warning:
...
[ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009cc00 (usable) [ 0.000000] BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) [ 0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used [ 0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used [ 0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used [ 0.000000] max_pfn_mapped = 1228800 [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] After WB checking [ 0.000000] MTRR MAP PFN: 0000000000000000 - 0000000000100000 [ 0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] After UC checking [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 [ 0.000000] After sorting [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf801000 - 00000000cf801000 [ 0.000000] range: 00000000cf801000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 4, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 5, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 6, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 7, base: 3320MB, range: 0MB, type WB [ 0.000000] range0: 0000000100001000 - 0000000110001000 [ 0.000000] range: 0000000110001000 - 0000000120001000 [ 0.000000] hole: 0000000120000000 - 0000000120001000 [ 0.000000] DONE variable MTRRs [ 0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106 [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1472MB of RAM. [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x154/0x18d() [ 0.000000] Modules linked in: [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.25-05561-g064922a-dirty #797 [ 0.000000] [ 0.000000] Call Trace: [ 0.000000] [<ffffffff802374f4>] warn_on_slowpath+0x64/0xb0 [ 0.000000] [<ffffffff8074ac5b>] mtrr_trim_uncached_memory+0x154/0x18d [ 0.000000] [<ffffffff80747a08>] setup_arch+0x356/0x599 [ 0.000000] [<ffffffff80740b6f>] start_kernel+0x5c/0x3b9 [ 0.000000] [<ffffffff80740425>] x86_64_start_kernel+0x225/0x270 [ 0.000000] [ 0.000000] ---[ end trace ca143223eefdc828 ]--- [ 0.000000] update e820 for mtrr [ 0.000000] modified physical RAM map: [ 0.000000] modified: 0000000000000000 - 000000000009cc00 (usable) [ 0.000000] modified: 000000000009cc00 - 00000000000a0000 (reserved) [ 0.000000] modified: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] modified: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] modified: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] modified: 00000000cf5e0000 - 00000000cf600000 (reserved) [ 0.000000] modified: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] modified: 00000000ffc00000 - 000000012c000000 (reserved) [ 0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used [ 0.000000] Entering add_active_range(0, 256, 849232) 3 entries of 256 used [ 0.000000] max_pfn_mapped = 1228800 [ 0.000000] init_memory_mapping
...
--($:~)-- cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcf801000 (3320MB), size= 4KB: write-back, count=1
reg04: base=0xcf802000 (3320MB), size= 8KB: write-back, count=1
reg05: base=0xcf804000 (3320MB), size= 16KB: write-back, count=1
reg06: base=0xcf808000 (3320MB), size= 32KB: write-back, count=1
reg07: base=0xcf810000 (3320MB), size= 64KB: write-back, count=1
--($:~)-- uname -a
Linux thor 2.6.25-05561-g064922a-dirty #797 SMP PREEMPT Mon Apr 28 10:30:06 CEST 2008 x86_64 GNU/Linux
Full dmesg can be found there :
http://frugalware.org/~crazy/mtrr/mtrr_dmesg
Quoted 3 lines
YH
Gabriel
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 196 lines · Gabriel C
Quoted 82 lines · Yinghai Lu
Quoted 73 lines · Gabriel C
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> wrote:
[PATCH]
x86_32: trim memory by updating e820 v3when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_get_capand use it inearly_cpu_detect, and movemtrr_bp_initearlyneed Justine to test with his special system with bug bios.
Signed-off-by Yinghai Lu <[email protected]>Speaking of mtrr and e820....
Could someone please take a peek at
http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?For some reason we seem to have turned this:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)into this:
Quoted 8 lines
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1which screws up the X server's attempt to map the video memory at
0xd0000000.I see that on my box with ASUS P5E-VM DO and 4G RAM.
It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.
Also I get the mtrr type mismatch message on 32 and 64 bit kernels.
...
[ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) ...cat
/proc/mtrr:Quoted 7 lines
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1Quoted 5 lines
please try the patch at
http://lkml.org/lkml/2008/4/28/52
with mtrr_chunk_size=1g
Hi,
With mtrr_chunk_size=1g my box won't boot :( ( just tested 64bit kernel ).
It does without but I get a warning:
...
[ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009cc00 (usable) [ 0.000000] BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved)[ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) [ 0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used [ 0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used [ 0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used [ 0.000000] max_pfn_mapped = 1228800 [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] After WB checking [ 0.000000] MTRR MAP PFN: 0000000000000000 - 0000000000100000 [ 0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] After UC checking [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 [ 0.000000] After sorting [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf801000 - 00000000cf801000 [ 0.000000] range: 00000000cf801000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 4, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 5, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 6, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 7, base: 3320MB, range: 0MB, type WB [ 0.000000] range0: 0000000100001000 - 0000000110001000 [ 0.000000] range: 0000000110001000 - 0000000120001000 [ 0.000000] hole: 0000000120000000 - 0000000120001000 [ 0.000000] DONE variable MTRRs [ 0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106 [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1472MB of RAM. [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x154/0x18d()[ 0.000000] Modules linked in: [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.25-05561-g064922a-dirty #797 [ 0.000000] [ 0.000000] Call Trace: [ 0.000000] [<ffffffff802374f4>] warn_on_slowpath+0x64/0xb0 [ 0.000000] [<ffffffff8074ac5b>] mtrr_trim_uncached_memory+0x154/0x18d [ 0.000000] [<ffffffff80747a08>] setup_arch+0x356/0x599 [ 0.000000] [<ffffffff80740b6f>] start_kernel+0x5c/0x3b9 [ 0.000000] [<ffffffff80740425>] x86_64_start_kernel+0x225/0x270[ 0.000000] [ 0.000000] ---[ end trace ca143223eefdc828 ]--- [ 0.000000] update e820 for mtrr [ 0.000000] modified physical RAM map: [ 0.000000] modified: 0000000000000000 - 000000000009cc00 (usable) [ 0.000000] modified: 000000000009cc00 - 00000000000a0000 (reserved) [ 0.000000] modified: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] modified: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] modified: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] modified: 00000000cf5e0000 - 00000000cf600000 (reserved) [ 0.000000] modified: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] modified: 00000000ffc00000 - 000000012c000000 (reserved) [ 0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used [ 0.000000] Entering add_active_range(0, 256, 849232) 3 entries of 256 used [ 0.000000] max_pfn_mapped = 1228800 [ 0.000000] init_memory_mapping...
--($:~)-- cat
/proc/mtrrreg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcf801000 (3320MB), size= 4KB: write-back, count=1
reg04: base=0xcf802000 (3320MB), size= 8KB: write-back, count=1reg05: base=0xcf804000 (3320MB), size= 16KB: write-back, count=1 reg06: base=0xcf808000 (3320MB), size= 32KB: write-back, count=1 reg07: base=0xcf810000 (3320MB), size= 64KB: write-back, count=1
Quoted 7 lines
--($:~)-- uname -a
Linux thor 2.6.25-05561-g064922a-dirty #797 SMP PREEMPT Mon Apr 28 10:30:06 CEST 2008x86_64GNU/LinuxFull dmesg can be found there :
please try v2 version
http://lkml.org/lkml/2008/4/28/115
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 199 lines · Yinghai Lu
Quoted 198 lines · Gabriel C
Quoted 82 lines · Yinghai Lu
Quoted 73 lines · Gabriel C
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> wrote:
[PATCH]
x86_32: trim memory by updating e820 v3when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_get_capand use it inearly_cpu_detect, and movemtrr_bp_initearlyneed Justine to test with his special system with bug bios.
Signed-off-by Yinghai Lu <[email protected]>Speaking of mtrr and e820....
Could someone please take a peek at
http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?For some reason we seem to have turned this:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)into this:
Quoted 8 lines
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1which screws up the X server's attempt to map the video memory at
0xd0000000.I see that on my box with ASUS P5E-VM DO and 4G RAM.
It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.
Also I get the mtrr type mismatch message on 32 and 64 bit kernels.
...
[ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) ...cat
/proc/mtrr:Quoted 7 lines
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1Quoted 5 lines
please try the patch at
http://lkml.org/lkml/2008/4/28/52
with mtrr_chunk_size=1g
Hi,
With mtrr_chunk_size=1g my box won't boot :( ( just tested 64bit kernel ).
It does without but I get a warning:
...
[ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009cc00 (usable) [ 0.000000] BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved)[ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) [ 0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used [ 0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used [ 0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used [ 0.000000] max_pfn_mapped = 1228800 [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] After WB checking [ 0.000000] MTRR MAP PFN: 0000000000000000 - 0000000000100000 [ 0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] After UC checking [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 [ 0.000000] After sorting [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf801000 - 00000000cf801000 [ 0.000000] range: 00000000cf801000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 4, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 5, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 6, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 7, base: 3320MB, range: 0MB, type WB [ 0.000000] range0: 0000000100001000 - 0000000110001000 [ 0.000000] range: 0000000110001000 - 0000000120001000 [ 0.000000] hole: 0000000120000000 - 0000000120001000 [ 0.000000] DONE variable MTRRs [ 0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106 [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1472MB of RAM. [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x154/0x18d()[ 0.000000] Modules linked in: [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.25-05561-g064922a-dirty #797 [ 0.000000] [ 0.000000] Call Trace: [ 0.000000] [<ffffffff802374f4>] warn_on_slowpath+0x64/0xb0 [ 0.000000] [<ffffffff8074ac5b>] mtrr_trim_uncached_memory+0x154/0x18d [ 0.000000] [<ffffffff80747a08>] setup_arch+0x356/0x599 [ 0.000000] [<ffffffff80740b6f>] start_kernel+0x5c/0x3b9 [ 0.000000] [<ffffffff80740425>] x86_64_start_kernel+0x225/0x270[ 0.000000] [ 0.000000] ---[ end trace ca143223eefdc828 ]--- [ 0.000000] update e820 for mtrr [ 0.000000] modified physical RAM map: [ 0.000000] modified: 0000000000000000 - 000000000009cc00 (usable) [ 0.000000] modified: 000000000009cc00 - 00000000000a0000 (reserved) [ 0.000000] modified: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] modified: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] modified: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] modified: 00000000cf5e0000 - 00000000cf600000 (reserved) [ 0.000000] modified: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] modified: 00000000ffc00000 - 000000012c000000 (reserved) [ 0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used [ 0.000000] Entering add_active_range(0, 256, 849232) 3 entries of 256 used [ 0.000000] max_pfn_mapped = 1228800 [ 0.000000] init_memory_mapping...
--($:~)-- cat
/proc/mtrrreg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcf801000 (3320MB), size= 4KB: write-back, count=1
reg04: base=0xcf802000 (3320MB), size= 8KB: write-back, count=1reg05: base=0xcf804000 (3320MB), size= 16KB: write-back, count=1 reg06: base=0xcf808000 (3320MB), size= 32KB: write-back, count=1 reg07: base=0xcf810000 (3320MB), size= 64KB: write-back, count=1--($:~)-- uname -a
Linux thor 2.6.25-05561-g064922a-dirty #797 SMP PREEMPT Mon Apr 28 10:30:06 CEST 2008x86_64GNU/Linux
Quoted 8 lines
Quoted 4 lines
Full dmesg can be found there :
please try v2 version
Box still won't boot with mtrr_chunk_size=1g but without it is perfect :)) Thx for your work. I've quick tested some games and 3d things , all are working with this patch really nice.
Full dmesg :
http://frugalware.org/~crazy/mtrr/mtrr2_dmesg
--($:~)-- cat /proc/mtrr
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcf800000 (3320MB), size= 8MB: write-back, count=1
reg04: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg05: base=0x120000000 (4608MB), size= 256MB: write-back, count=1
reg06: base=0x12c000000 (4800MB), size= 64MB: uncachable, count=1
reg07: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1
If you wish I can test 32bit too a bit later , just let me know.
Quoted 3 lines
YH
Gabriel
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 227 lines · Gabriel C
Quoted 199 lines · Yinghai Lu
Quoted 198 lines · Gabriel C
Quoted 82 lines · Yinghai Lu
Quoted 73 lines · Gabriel C
Quoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> wrote:
[PATCH]
x86_32: trim memory by updating e820 v3when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_get_capand use it inearly_cpu_detect, and movemtrr_bp_initearlyneed Justine to test with his special system with bug bios.
Signed-off-by Yinghai Lu <[email protected]>Speaking of mtrr and e820....
Could someone please take a peek at
http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?For some reason we seem to have turned this:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)into this:
Quoted 8 lines
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1which screws up the X server's attempt to map the video memory at
0xd0000000.I see that on my box with ASUS P5E-VM DO and 4G RAM.
It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS.I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit.
Also I get the mtrr type mismatch message on 32 and 64 bit kernels.
...
[ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved)[ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) ...cat
/proc/mtrr:Quoted 7 lines
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1Quoted 5 lines
please try the patch at
http://lkml.org/lkml/2008/4/28/52
with mtrr_chunk_size=1g
Hi,
With mtrr_chunk_size=1g my box won't boot :( ( just tested 64bit kernel ).
It does without but I get a warning:
...
[ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009cc00 (usable) [ 0.000000] BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved)[ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) [ 0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used [ 0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used [ 0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used [ 0.000000] max_pfn_mapped = 1228800 [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] After WB checking [ 0.000000] MTRR MAP PFN: 0000000000000000 - 0000000000100000 [ 0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] After UC checking [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 [ 0.000000] After sorting [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf801000 - 00000000cf801000 [ 0.000000] range: 00000000cf801000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 4, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 5, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 6, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 7, base: 3320MB, range: 0MB, type WB [ 0.000000] range0: 0000000100001000 - 0000000110001000 [ 0.000000] range: 0000000110001000 - 0000000120001000 [ 0.000000] hole: 0000000120000000 - 0000000120001000 [ 0.000000] DONE variable MTRRs [ 0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106 [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1472MB of RAM. [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x154/0x18d()[ 0.000000] Modules linked in: [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.25-05561-g064922a-dirty #797 [ 0.000000] [ 0.000000] Call Trace: [ 0.000000] [<ffffffff802374f4>] warn_on_slowpath+0x64/0xb0 [ 0.000000] [<ffffffff8074ac5b>] mtrr_trim_uncached_memory+0x154/0x18d [ 0.000000] [<ffffffff80747a08>] setup_arch+0x356/0x599 [ 0.000000] [<ffffffff80740b6f>] start_kernel+0x5c/0x3b9 [ 0.000000] [<ffffffff80740425>] x86_64_start_kernel+0x225/0x270[ 0.000000] [ 0.000000] ---[ end trace ca143223eefdc828 ]--- [ 0.000000] update e820 for mtrr [ 0.000000] modified physical RAM map: [ 0.000000] modified: 0000000000000000 - 000000000009cc00 (usable) [ 0.000000] modified: 000000000009cc00 - 00000000000a0000 (reserved) [ 0.000000] modified: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] modified: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] modified: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] modified: 00000000cf5e0000 - 00000000cf600000 (reserved) [ 0.000000] modified: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] modified: 00000000ffc00000 - 000000012c000000 (reserved) [ 0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used [ 0.000000] Entering add_active_range(0, 256, 849232) 3 entries of 256 used [ 0.000000] max_pfn_mapped = 1228800 [ 0.000000] init_memory_mapping...
--($:~)-- cat
/proc/mtrrreg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcf801000 (3320MB), size= 4KB: write-back, count=1
reg04: base=0xcf802000 (3320MB), size= 8KB: write-back, count=1reg05: base=0xcf804000 (3320MB), size= 16KB: write-back, count=1 reg06: base=0xcf808000 (3320MB), size= 32KB: write-back, count=1 reg07: base=0xcf810000 (3320MB), size= 64KB: write-back, count=1--($:~)-- uname -a
Linux thor 2.6.25-05561-g064922a-dirty #797 SMP PREEMPT Mon Apr 28 10:30:06 CEST 2008x86_64GNU/LinuxQuoted 7 lines
Quoted 4 lines
Full dmesg can be found there :
please try v2 version
Box still won't boot with mtrr_chunk_size=1g but without it is perfect :)) Thx for your work. I've quick tested some games and 3d things , all are working with this patch really nice.
Full dmesg :
http://frugalware.org/~crazy/mtrr/mtrr2_dmesg
--($:~)-- cat
/proc/mtrr
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1
reg03: base=0xcf800000 (3320MB), size= 8MB: write-back, count=1
reg04: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg05: base=0x120000000 (4608MB), size= 256MB: write-back, count=1
reg06: base=0x12c000000 (4800MB), size= 64MB: uncachable, count=1
reg07: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1
Quoted 1 line
If you wish I can test 32bit too a bit later , just let me know.
BTW I just saw , there is this warning now :
[ 0.305539] mtrr: your CPUs had inconsistent variable MTRR settings [ 0.305546] mtrr: probably your BIOS does not setup all CPUs. [ 0.305553] mtrr: corrected configuration.
but everything seems to work fine.
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 7 lines · Gabriel C
BTW I just saw , there is this warning now :
[ 0.305539] mtrr: your CPUs had inconsistent variable MTRR settings [ 0.305546] mtrr: probably your BIOS does not setup all CPUs. [ 0.305553] mtrr: corrected configuration.but everything seems to work fine.
Just, FYI, I got this warning too. I didn't get it before applying the patch.
Regards,
Mika
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 11 lines · Mika Fischer
Quoted 7 lines · Gabriel C
BTW I just saw , there is this warning now :
[ 0.305539] mtrr: your CPUs had inconsistent variable MTRR settings [ 0.305546] mtrr: probably your BIOS does not setup all CPUs. [ 0.305553] mtrr: corrected configuration.but everything seems to work fine.
Just, FYI, I got this warning too. I didn't get it before applying the patch.
that is normal. because APs will copy the changes of MTRR from BP. could add some condition for the print out.
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
In reply to Gabriel CQuoted 7 lines · Gabriel C
Quoted 3 lines
please try v2 version
Box still won't boot with mtrr_chunk_size=1g but without it is perfect :)) Thx for your work. I've quick tested some games and 3d things , all are working with this patch really nice.
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
so fixing up the MTRRs during bootup, no matter how dangerous in theory, is pretty much the best option to get your system to work fine under Linux, with that specific Xorg version?
i think we should still try to make this a non-default option because modern Xorg should not have any need to touch MTRRs. Perhaps a .config dependent on CONFIG_DANGEROUS ;-)
Ingo
Re: [PATCH] x86_32: trim memory by updating e820 v3
Hi Ingo,
I'm having the same problem.
Quoted 3 lines · Ingo Molnar
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc.
And this always happens with 4GB RAM, but not with 2GB RAM.
So yes, with this patch for the first time X works at normal speed with 4GB of RAM out of the box.
Quoted 3 lines
so fixing up the MTRRs during bootup, no matter how dangerous in theory, is pretty much the best option to get your system to work fine under Linux, with that specific Xorg version?
Yes. That's what I'm doing at the moment with a shell script. :)
Quoted 3 lines
i think we should still try to make this a non-default option because modern Xorg should not have any need to touch MTRRs. Perhaps a .config dependent on
CONFIG_DANGEROUS;-)
AFAICT X always tries to set up a write-combining range for the video memory. And this will always fail if there are erroneous write-back or even uncachable ranges overlapping the video memory...
But I don't know if this has changed in newer versions of Xorg (I'm using 7.3).
In any case if I have a range in /proc/mtrr that is declared uncachable and overlaps my video memory (which is the case without this patch), is there even anything Xorg can do to make the video-memory use write-combining?
Regards,
Mika
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 5 lines · Mika Fischer
Hi Ingo,
I'm having the same problem.
Ingo Molnar schrieb:
Quoted 8 lines
Quoted 3 lines
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc.
Well you are lucky then :)
Yeah X 'worked' but it worked as slow as with vesa video driver here.
Also starting something like supertuxkart made it crash or I got a black screen :(
The only game I managed to start ( without X to crash ) without that patch was supertux but is was slow as hell. However I'm not a gamer but I need X to work right.
Quoted 3 lines
Regards,
Mika
Gabriel
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer
Hi Ingo,
I'm having the same problem.
Quoted 3 lines · Ingo Molnar
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
Quoted 8 lines
Quoted 4 lines
Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc.
Well you are lucky then :)
Yeah X 'worked' but it worked as slow as with vesa video driver here.
[ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 [ 0.000000] range: 00000000cf800000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] range0: 0000000100000000 - 0000000120000000 [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] range: 0000000120000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] hole: 000000012c000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
so your X server need two entries for WB?
can you send out /proc/mtrr with booting with disable_mtrr_cleanup?
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 34 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer
Hi Ingo,
I'm having the same problem.
Quoted 3 lines · Ingo Molnar
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
Quoted 8 lines
Quoted 4 lines
Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc.
Well you are lucky then :)
Yeah X 'worked' but it worked as slow as with vesa video driver here.
[ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 [ 0.000000] range: 00000000cf800000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] range0: 0000000100000000 - 0000000120000000 [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] range: 0000000120000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] hole: 000000012c000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
Quoted 3 lines
so your X server need two entries for WB?
can you send out
/proc/mtrrwith booting withdisable_mtrr_cleanup?
I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
Quoted 3 lines
YH
Gabriel
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer
Hi Ingo,
I'm having the same problem.
Quoted 3 lines · Ingo Molnar
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
Quoted 8 lines
Quoted 4 lines
Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc.
Well you are lucky then :)
Yeah X 'worked' but it worked as slow as with vesa video driver here.
[ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 [ 0.000000] range: 00000000cf800000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] range0: 0000000100000000 - 0000000120000000 [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] range: 0000000120000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] hole: 000000012c000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
Quoted 5 lines
Quoted 3 lines
so your X server need two entries for WB?
can you send out
/proc/mtrrwith booting withdisable_mtrr_cleanup?I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
Here the output with v3 which is disabled by default:
--($:~)-- cat /proc/mtrr
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1
dmesg is saying now :
[ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
My card settings in BIOS ( that was default ) are the following :
DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )
Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) PEG Port -> Auto ( possible settings Auto , Disabled )
PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )
Of course these settings are only possible when the card is not disabled :)
I'm gonna try v4 now and enable it. Please let me know if you need more infos.
Gabriel
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 61 lines · Gabriel C
Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer
Hi Ingo,
I'm having the same problem.
Quoted 3 lines · Ingo Molnar
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
Quoted 8 lines
Quoted 4 lines
Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc.
Well you are lucky then :)
Yeah X 'worked' but it worked as slow as with vesa video driver here.
[ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 [ 0.000000] range: 00000000cf800000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] range0: 0000000100000000 - 0000000120000000 [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] range: 0000000120000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] hole: 000000012c000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UCQuoted 4 lines
Quoted 3 lines
so your X server need two entries for WB?
can you send out
/proc/mtrrwith booting withdisable_mtrr_cleanup?I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
Here the output with v3 which is disabled by default:
--($:~)-- cat
/proc/mtrr
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1dmesg is saying now :
[ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combiningMy card settings in BIOS ( that was default ) are the following :
DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )
Quoted 8 lines
Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) PEG Port -> Auto ( possible settings Auto , Disabled )
PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )Of course these settings are only possible when the card is not disabled :)
I'm gonna try v4 now and enable it. Please let me know if you need more infos.
Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ). It takes 6 minutes to boot to :
sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray
after that the box hangs :/
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 68 lines · Gabriel C
Quoted 66 lines · Gabriel C
Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer
Hi Ingo,
I'm having the same problem.
Quoted 3 lines · Ingo Molnar
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
Quoted 8 lines
Quoted 4 lines
Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc.
Well you are lucky then :)
Yeah X 'worked' but it worked as slow as with vesa video driver here.
[ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 [ 0.000000] range: 00000000cf800000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] range0: 0000000100000000 - 0000000120000000 [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] range: 0000000120000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] hole: 000000012c000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UCQuoted 4 lines
Quoted 3 lines
so your X server need two entries for WB?
can you send out
/proc/mtrrwith booting withdisable_mtrr_cleanup?I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
Here the output with v3 which is disabled by default:
--($:~)-- cat
/proc/mtrr
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1dmesg is saying now :
[ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combiningMy card settings in BIOS ( that was default ) are the following :
DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )
Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) PEG Port -> Auto ( possible settings Auto , Disabled )
PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )
Quoted 7 lines
Quoted 3 lines
Of course these settings are only possible when the card is not disabled :)
I'm gonna try v4 now and enable it. Please let me know if you need more infos.
Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ). It takes 6 minutes to boot to :
so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is another 8M address.
mtrr by BIOS is very interesting:
before
Quoted 7 lines
Quoted 7 lines
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
after 256M chunk size got
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
[ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC
so the convering is right..., need to spare another entry for your card.
or we can dumping the
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
[ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB
for extra entra...
but the mtrr trimming code need to be updated instead of only using highest_pfn
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 70 lines · Yinghai Lu
Quoted 69 lines · Gabriel C
Quoted 68 lines · Gabriel C
Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer
Hi Ingo,
I'm having the same problem.
Quoted 3 lines · Ingo Molnar
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
Quoted 8 lines
Quoted 4 lines
Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc.
Well you are lucky then :)
Yeah X 'worked' but it worked as slow as with vesa video driver here.
[ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 [ 0.000000] range: 00000000cf800000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] range0: 0000000100000000 - 0000000120000000 [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] range: 0000000120000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] hole: 000000012c000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UCQuoted 4 lines
Quoted 3 lines
so your X server need two entries for WB?
can you send out
/proc/mtrrwith booting withdisable_mtrr_cleanup?I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
Here the output with v3 which is disabled by default:
--($:~)-- cat
/proc/mtrr
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1dmesg is saying now :
[ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combiningMy card settings in BIOS ( that was default ) are the following :
DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )
Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) PEG Port -> Auto ( possible settings Auto , Disabled )
PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )Of course these settings are only possible when the card is not disabled :)
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
I'm gonna try v4 now and enable it. Please let me know if you need more infos.
Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ). It takes 6 minutes to boot to :
so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is another 8M address.
Looks like this , yes. Is using the 256MB Memory and the 8MB for Graphics Mode Select.
I'm not really sure why the 8MB are needed , BIOS book doesn't tell me. I could try to disable and see what I get =)
Quoted 23 lines
mtrr by BIOS is very interesting:
beforeQuoted 7 lines
Quoted 7 lines
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1after 256M chunk size got
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
[ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UCso the convering is right..., need to spare another entry for your card.
Quoted 8 lines
or we can dumping the
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
[ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WBfor extra entra...
but the mtrr trimming code need to be updated instead of only using
highest_pfnYH
Gabriel
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 78 lines · Gabriel C
Quoted 76 lines · Yinghai Lu
Quoted 74 lines · Gabriel C
Quoted 61 lines · Gabriel C
Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer
Hi Ingo,
I'm having the same problem.
Quoted 3 lines · Ingo Molnar
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
Quoted 8 lines
Quoted 4 lines
Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc.
Well you are lucky then :)
Yeah X 'worked' but it worked as slow as with vesa video driver here.
[ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 [ 0.000000] range: 00000000cf800000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] range0: 0000000100000000 - 0000000120000000 [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] range: 0000000120000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] hole: 000000012c000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UCQuoted 4 lines
Quoted 3 lines
so your X server need two entries for WB?
can you send out
/proc/mtrrwith booting withdisable_mtrr_cleanup?I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
Here the output with v3 which is disabled by default:
--($:~)-- cat
/proc/mtrr
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1dmesg is saying now :
[ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combiningMy card settings in BIOS ( that was default ) are the following :
DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )
Quoted 8 lines
Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) PEG Port -> Auto ( possible settings Auto , Disabled )
PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )Of course these settings are only possible when the card is not disabled :)
I'm gonna try v4 now and enable it. Please let me know if you need more infos.
Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ). It takes 6 minutes to boot to :
Quoted 41 lines
Quoted 2 lines
so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is another 8M address.
Looks like this , yes. Is using the 256MB Memory and the 8MB for Graphics Mode Select.
I'm not really sure why the 8MB are needed , BIOS book doesn't tell me. I could try to disable and see what I get =)
Quoted 31 lines
mtrr by BIOS is very interesting:
beforeQuoted 7 lines
Quoted 7 lines
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1after 256M chunk size got
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
[ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UCso the convering is right..., need to spare another entry for your card.
or we can dumping the
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
[ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WBfor extra entra...
but the mtrr trimming code need to be updated instead of only using
highest_pfnYH
please try to test patch with mtrr_chunk_size= 2g; 1g, 512m, 128m. etc. only for test: i comment out the fill_var_state..
YH
[PATCH] x86: mtrr cleanup for converting continuous to discrete layout v5
some BIOS like to use continus MTRR layout, and may X driver can not add WB entries for graphical cards when 4g or more RAM installed.
the patch will change MTRR to discrete.
mtrr_chunk_size= could be used to have smaller continuous block to hold holes. default is 256m, could be set according to size of graphics card memory.
v2: fix -1 for UC checking
v3: default to disable, and need use enable_mtrr_cleanup to enable this feature
skip the var state change warning.
remove next_basek in range_to_mtrr()
v4: correct warning mask.
v5: CONFIG_MTRR_SANITIZER
arch/x86/kernel/cpu/mtrr/generic.c +14 -0
@@ -158,6 +158,20 @@ get_mtrr_var_range(unsigned int index, srdmsr (MTRRphysMask_MSR (index), vr->mask_lo, vr->mask_hi); } +/* fill the MSR pair relating to a var range */ +void fill_mtrr_var_range (unsigned int index, +u32 base_lo,u32 base_hi,u32 mask_lo,u32 mask_hi) +{ +struct mtrr_var_range *vr; + + vr = mtrr_state.var_ranges; + + vr[index].base_lo = base_lo; + vr[index].base_hi = base_hi; + vr[index].mask_lo = mask_lo; + vr[index].mask_hi = mask_hi; +} +static void get_fixed_ranges (mtrr_type * frs) {
arch/x86/kernel/cpu/mtrr/main.c +376 -5
429 lines not on this page · raw message
arch/x86/kernel/cpu/mtrr/mtrr.h +2 -0
@@ -81,6 +81,8 @@ void set_mtrr_done(struct set_mtrr_contevoid set_mtrr_cache_disable (struct set_mtrr_context *ctxt);void set_mtrr_prepare_save (struct set_mtrr_context *ctxt); +void fill_mtrr_var_range (unsigned int index, +u32 base_lo,u32 base_hi,u32 mask_lo,u32 mask_hi);void get_mtrr_state (void );extern void set_mtrr_ops (struct mtrr_ops * ops);
Documentation/kernel-parameters.txt +10 -0
@@ -595,6 +595,16 @@ and is between 256 and 4096 characters. See drivers/char/README.epca and Documentation/digiepca.txt. + disable_mtrr_cleanup [X86] + enable_mtrr_cleanup [X86] + The kernel tries to adjust MTRR layout from continuous + to discrete, to make X server driver able to add WB + entry later. This parameter enables/disables that. + + mtrr_chunk_size=nn[KMG] [X86] + used for mtrr cleanup. It is largest continous chunk + that could hold holes aka. UC entries. + disable_mtrr_trim [X86, Intel and AMD only] By default the kernel will trim any uncacheable memory out of your available memory pool based on
arch/x86/Kconfig +26 -0
@@ -1035,6 +1035,32 @@ config MTRR See <file:Documentation/mtrr.txt> for more information. +config MTRR_SANITIZER + def_bool y + prompt "MTRR cleanup support" + depends on MTRR + help + Convert MTRR layout from continuous to discrete, so some X driver + could add WB entries. + + Say N here if you see bootup problems (boot crash, boot hang, + spontaneous reboots). + + Could be disabled with disable_mtrr_cleanup. Also mtrr_chunk_size + could be used to send largest mtrr entry size for continuous block + to hold holes (aka. UC entries) + + If unsure, say Y. + +config MTRR_SANITIZER_ENABLE_DEFAULT + def_bool y + prompt "Enable MTRR cleanup by default" + depends on MTRR_SANITIZER + help + Enable mtrr cleanup by default + + If unsure, say Y. + config X86_PAT bool prompt "x86 PAT support"
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 115 lines · Yinghai Lu
Quoted 114 lines · Gabriel C
Quoted 70 lines · Yinghai Lu
Quoted 69 lines · Gabriel C
Quoted 68 lines · Gabriel C
Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer
Hi Ingo,
I'm having the same problem.
Quoted 3 lines · Ingo Molnar
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
Quoted 8 lines
Quoted 4 lines
Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc.
Well you are lucky then :)
Yeah X 'worked' but it worked as slow as with vesa video driver here.
[ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 [ 0.000000] range: 00000000cf800000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] range0: 0000000100000000 - 0000000120000000 [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] range: 0000000120000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] hole: 000000012c000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UCQuoted 4 lines
Quoted 3 lines
so your X server need two entries for WB?
can you send out
/proc/mtrrwith booting withdisable_mtrr_cleanup?I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
Here the output with v3 which is disabled by default:
--($:~)-- cat
/proc/mtrr
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1dmesg is saying now :
[ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combiningMy card settings in BIOS ( that was default ) are the following :
DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )
Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) PEG Port -> Auto ( possible settings Auto , Disabled )
PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )Of course these settings are only possible when the card is not disabled :)
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
I'm gonna try v4 now and enable it. Please let me know if you need more infos.
Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ). It takes 6 minutes to boot to :
so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is another 8M address.
Looks like this , yes. Is using the 256MB Memory and the 8MB for Graphics Mode Select.
I'm not really sure why the 8MB are needed , BIOS book doesn't tell me. I could try to disable and see what I get =)
Quoted 27 lines
mtrr by BIOS is very interesting:
beforeQuoted 7 lines
Quoted 7 lines
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1after 256M chunk size got
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
[ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UCso the convering is right..., need to spare another entry for your card.
or we can dumping the
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
[ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WBfor extra entra...
Quoted 7 lines
Quoted 4 lines
Quoted 4 lines
but the mtrr trimming code need to be updated instead of only using
highest_pfnYH
please try to test patch with mtrr_chunk_size= 2g; 1g, 512m, 128m. etc. only for test: i comment out the
fill_var_state..
There are the dmesg's , down to 2m and without chunk_size :
http://frugalware.org/~crazy/mtrr/mtrr/
Quoted 3 lines
YH
Gabriel
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 122 lines · Gabriel C
Quoted 120 lines · Yinghai Lu
Quoted 118 lines · Gabriel C
Quoted 70 lines · Yinghai Lu
Quoted 69 lines · Gabriel C
Quoted 68 lines · Gabriel C
Quoted 34 lines · Gabriel C
Quoted 33 lines · Yinghai Lu
Quoted 10 lines · Gabriel C
Quoted 9 lines · Mika Fischer
Hi Ingo,
I'm having the same problem.
Quoted 3 lines · Ingo Molnar
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
Quoted 8 lines
Quoted 4 lines
Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc.
Well you are lucky then :)
Yeah X 'worked' but it worked as slow as with vesa video driver here.
[ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 [ 0.000000] range: 00000000cf800000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] range0: 0000000100000000 - 0000000120000000 [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] range: 0000000120000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] hole: 000000012c000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UCQuoted 4 lines
Quoted 3 lines
so your X server need two entries for WB?
can you send out
/proc/mtrrwith booting withdisable_mtrr_cleanup?I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less.
Here the output with v3 which is disabled by default:
--($:~)-- cat
/proc/mtrr
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1dmesg is saying now :
[ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combiningMy card settings in BIOS ( that was default ) are the following :
DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT )
Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD )
Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) PEG Port -> Auto ( possible settings Auto , Disabled )
PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled )Of course these settings are only possible when the card is not disabled :)
Quoted 8 lines
Quoted 5 lines
Quoted 1 line
I'm gonna try v4 now and enable it. Please let me know if you need more infos.
Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ). It takes 6 minutes to boot to :
so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is another 8M address.
Looks like this , yes. Is using the 256MB Memory and the 8MB for Graphics Mode Select.
I'm not really sure why the 8MB are needed , BIOS book doesn't tell me. I could try to disable and see what I get =)
Quoted 31 lines
mtrr by BIOS is very interesting:
beforeQuoted 7 lines
Quoted 7 lines
reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1
reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1
reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1
reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1
reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1
reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1after 256M chunk size got
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
Quoted 7 lines
[ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UCso the convering is right..., need to spare another entry for your card.
or we can dumping the
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
[ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WBfor extra entra...
but the mtrr trimming code need to be updated instead of only using
highest_pfnYH
Quoted 6 lines
Quoted 2 lines
please try to test patch with mtrr_chunk_size= 2g; 1g, 512m, 128m. etc. only for test: i comment out the
fill_var_state..There are the dmesg's , down to 2m and without
chunk_size:
please check this one v6 test.
please only check =2g, 1g, and 512m, 256m, 128m, 64m.
Thanks
Yinghai Lu
[PATCH] x86: mtrr cleanup for converting continuous to discrete layout v6
some BIOS like to use continus MTRR layout, and may X driver can not add WB entries for graphical cards when 4g or more RAM installed.
the patch will change MTRR to discrete.
mtrr_chunk_size= could be used to have smaller continuous block to hold holes. default is 256m, could be set according to size of graphics card memory.
v2: fix -1 for UC checking
v3: default to disable, and need use enable_mtrr_cleanup to enable this feature
skip the var state change warning.
remove next_basek in range_to_mtrr()
v4: correct warning mask.
v5: CONFIG_MTRR_SANITIZER
v6: 1g, 2g, 512 aligment with extra hole
arch/x86/kernel/cpu/mtrr/generic.c +14 -0
@@ -158,6 +158,20 @@ get_mtrr_var_range(unsigned int index, srdmsr (MTRRphysMask_MSR (index), vr->mask_lo, vr->mask_hi); } +/* fill the MSR pair relating to a var range */ +void fill_mtrr_var_range (unsigned int index, +u32 base_lo,u32 base_hi,u32 mask_lo,u32 mask_hi) +{ +struct mtrr_var_range *vr; + + vr = mtrr_state.var_ranges; + + vr[index].base_lo = base_lo; + vr[index].base_hi = base_hi; + vr[index].mask_lo = mask_lo; + vr[index].mask_hi = mask_hi; +} +static void get_fixed_ranges (mtrr_type * frs) {
arch/x86/kernel/cpu/mtrr/main.c +385 -5
438 lines not on this page · raw message
arch/x86/kernel/cpu/mtrr/mtrr.h +2 -0
@@ -81,6 +81,8 @@ void set_mtrr_done(struct set_mtrr_contevoid set_mtrr_cache_disable (struct set_mtrr_context *ctxt);void set_mtrr_prepare_save (struct set_mtrr_context *ctxt); +void fill_mtrr_var_range (unsigned int index, +u32 base_lo,u32 base_hi,u32 mask_lo,u32 mask_hi);void get_mtrr_state (void );extern void set_mtrr_ops (struct mtrr_ops * ops);
Documentation/kernel-parameters.txt +10 -0
@@ -595,6 +595,16 @@ and is between 256 and 4096 characters. See drivers/char/README.epca and Documentation/digiepca.txt. + disable_mtrr_cleanup [X86] + enable_mtrr_cleanup [X86] + The kernel tries to adjust MTRR layout from continuous + to discrete, to make X server driver able to add WB + entry later. This parameter enables/disables that. + + mtrr_chunk_size=nn[KMG] [X86] + used for mtrr cleanup. It is largest continous chunk + that could hold holes aka. UC entries. + disable_mtrr_trim [X86, Intel and AMD only] By default the kernel will trim any uncacheable memory out of your available memory pool based on
arch/x86/Kconfig +26 -0
@@ -1035,6 +1035,32 @@ config MTRR See <file:Documentation/mtrr.txt> for more information. +config MTRR_SANITIZER + def_bool y + prompt "MTRR cleanup support" + depends on MTRR + help + Convert MTRR layout from continuous to discrete, so some X driver + could add WB entries. + + Say N here if you see bootup problems (boot crash, boot hang, + spontaneous reboots). + + Could be disabled with disable_mtrr_cleanup. Also mtrr_chunk_size + could be used to send largest mtrr entry size for continuous block + to hold holes (aka. UC entries) + + If unsure, say Y. + +config MTRR_SANITIZER_ENABLE_DEFAULT + def_bool y + prompt "Enable MTRR cleanup by default" + depends on MTRR_SANITIZER + help + Enable mtrr cleanup by default + + If unsure, say Y. + config X86_PAT bool prompt "x86 PAT support"
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 7 lines · Yinghai Lu
v2: fix -1 for UC checking
v3: default to disable, and need useenable_mtrr_cleanupto enable this feature
skip the var state change warning.
removenext_basekinrange_to_mtrr()
v4: correct warning mask.
v5:CONFIG_MTRR_SANITIZER
v6: 1g, 2g, 512 aligment with extra hole
thanks Yinghai, i picked up v6.
Ingo
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 11 lines · Ingo Molnar
Quoted 7 lines · Yinghai Lu
v2: fix -1 for UC checking
v3: default to disable, and need useenable_mtrr_cleanupto enable this feature
skip the var state change warning.
removenext_basekinrange_to_mtrr()
v4: correct warning mask.
v5:CONFIG_MTRR_SANITIZER
v6: 1g, 2g, 512 aligment with extra hole
Quoted 1 line
thanks Yinghai, i picked up v6.
please use v8 instead. will send it out in minutes.
also it need
[PATCH 2/2] x86: fix trimming e820 with MTRR holes.
it could check range is not coverred below 4g when 8g ram installed.
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
In reply to Gabriel CQuoted 15 lines · Gabriel C
Quoted 5 lines · Mika Fischer
Hi Ingo,
I'm having the same problem.
Ingo Molnar schrieb:
Quoted 8 lines
Quoted 3 lines
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc.
Quoted 9 lines
Well you are lucky then :)
Yeah X 'worked' but it worked as slow as with vesa video driver here.
Also starting something like supertuxkart made it crash or I got a black screen :(
The only game I managed to start ( without X to crash ) without that patch was supertux but is was slow as hell. However I'm not a gamer but I need X to work right.
or can you change graphics card memory in BIOS to some big like 256M instead of 64M?
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 20 lines · Yinghai Lu
Quoted 19 lines · Gabriel C
Quoted 5 lines · Mika Fischer
Hi Ingo,
I'm having the same problem.
Ingo Molnar schrieb:
Quoted 8 lines
Quoted 3 lines
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc.
Well you are lucky then :)
Yeah X 'worked' but it worked as slow as with vesa video driver here.
Quoted 8 lines
Quoted 5 lines
Also starting something like supertuxkart made it crash or I got a black screen :(
The only game I managed to start ( without X to crash ) without that patch was supertux but is was slow as hell. However I'm not a gamer but I need X to work right.
or can you change graphics card memory in BIOS to some big like 256M instead of 64M?
It is set to 256M , I cannot even set it to 64MB in BIOS.
I have options for 128/256 MB only and I think I can change the mode to fixed.
Quoted 2 lines
YH
Gabriel
Re: [PATCH] x86_32: trim memory by updating e820 v3
In reply to Ingo MolnarQuoted 4 lines · Ingo Molnar
Quoted 2 lines · Gabriel C
Quoted 2 lines
please try v2 version
Quoted 8 lines
Quoted 4 lines
Quoted 1 line
Box still won't boot with mtrr_chunk_size=1g but without it is perfect :)) Thx for your work. I've quick tested some games and 3d things , all are working with this patch really nice.
excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right?
The box is really new so far I tested 2.6.24* 2.6.25 , linux-next , current git from which no one worked. And yes is right graphics under Linux didn't worked right without patch from http://lkml.org/lkml/2008/4/28/115.
Quoted 4 lines
so fixing up the MTRRs during bootup, no matter how dangerous in theory, is pretty much the best option to get your system to work fine under Linux, with that specific Xorg version?
Yes.
I run :
xorg-server 1.4.0.90-5 ( it has all fixes from server-1.4-branch ) mesa 7.0.2-2
xf86-video-intel 2.3.0-1
Probably I have to replace 2x2G with 2x1G to get it work without this patch but it is something I don't really want to do =)
Also I'm not sure whatever this is an BIOS bug ? I could contact ASUS people if someone tells me what is wrong with the BIOS.
Quoted 4 lines
i think we should still try to make this a non-default option because modern Xorg should not have any need to touch MTRRs. Perhaps a .config dependent on
CONFIG_DANGEROUS;-)
Hmm 1.4.0.90 is not that old , is it ?
Quoted 3 lines
Ingo
Gabriel
Re: [PATCH] x86_32: trim memory by updating e820 v3
In reply to Ingo MolnarQuoted 3 lines · Ingo Molnar
i think we should still try to make this a non-default option because modern Xorg should not have any need to touch MTRRs. Perhaps a .config dependent on
CONFIG_DANGEROUS;-)
Well, not quite... we're still waiting on some way of getting WC semantics for sysfs PCI files. Suresh tells me something like that is queued up, but until that hits the mainline X will still need to bang the MTRRs to get decent performance.
Jesse
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 9 lines · Jesse Barnes
Quoted 3 lines · Ingo Molnar
i think we should still try to make this a non-default option because modern Xorg should not have any need to touch MTRRs. Perhaps a .config dependent on
CONFIG_DANGEROUS;-)Well, not quite... we're still waiting on some way of getting WC semantics for sysfs PCI files. Suresh tells me something like that is queued up, but until that hits the mainline X will still need to bang the MTRRs to get decent performance.
Do you happen to know if this new sysfs-way will work correctly in the case where the MTRRs explicitly say that the video-memory is uncachable?
Regards,
Mika
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 6 lines · Mika Fischer
Quoted 5 lines · Jesse Barnes
Quoted 3 lines · Ingo Molnar
i think we should still try to make this a non-default option because modern Xorg should not have any need to touch MTRRs. Perhaps a .config dependent on
CONFIG_DANGEROUS;-)
Quoted 7 lines
Quoted 4 lines
Well, not quite... we're still waiting on some way of getting WC semantics for sysfs PCI files. Suresh tells me something like that is queued up, but until that hits the mainline X will still need to bang the MTRRs to get decent performance.
Do you happen to know if this new sysfs-way will work correctly in the case where the MTRRs explicitly say that the video-memory is uncachable?
It should, since we'll be using PAT to set the cache control in the sysfs case.
Jesse
Re: [PATCH] x86_32: trim memory by updating e820 v3
In reply to Jesse BarnesQuoted 8 lines · Jesse Barnes
Quoted 3 lines
i think we should still try to make this a non-default option because modern Xorg should not have any need to touch MTRRs. Perhaps a .config dependent on
CONFIG_DANGEROUS;-)Well, not quite... we're still waiting on some way of getting WC semantics for sysfs PCI files. Suresh tells me something like that is queued up, but until that hits the mainline X will still need to bang the MTRRs to get decent performance.
yes, the patch below is queued up for an eventual v2.6.26 merge. If it looks fine to you, could you please ack it so that we can send it to Linus? I'd like to do this after some pending PAT fixes are upstream.
Ingo
---------------->
Subject: x86, PAT: export resource_wc in pci sysfs
From: [email protected]
Date: Tue, 18 Mar 2008 17:00:22 -0700
For the ranges with IORESOURCE_PREFETCH, export a new resource_wc interface in pci /sysfs along with resource (which is uncached).
--- Documentation/filesystems/sysfs-pci.txt | 1 drivers/pci/pci-sysfs.c | 82 +++++++++++++++++++++++--------- include/linux/pci.h | 1 3 files changed, 63 insertions(+), 21 deletions(-)
Documentation/filesystems/sysfs-pci.txt +1 -0
@@ -36,6 +36,7 @@ files, each with their own function. local_cpus nearby CPU mask (cpumask, ro) resource PCI resource host addresses (ascii, ro) resource0..N PCI resource N, if present (binary, mmap) + resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap) rom PCI ROM resource, if present (binary, ro) subsystem_device PCI subsystem device (ascii, ro) subsystem_vendor PCI subsystem vendor (ascii, ro)
drivers/pci/pci-sysfs.c +61 -21
121 lines not on this page · raw message
include/linux/pci.h +1 -0
@@ -205,6 +205,7 @@ struct pci_dev {struct bin_attribute *rom_attr;/* attribute descriptor for sysfs ROM entry */ int rom_attr_enabled;/* has display of the rom attribute been enabled? */ struct bin_attribute *res_attr[DEVICE_COUNT_RESOURCE ];/* sysfs file for resources */ +struct bin_attribute *res_attr_wc[DEVICE_COUNT_RESOURCE ];/* sysfs file for WC mapping of resources */ #ifdef CONFIG_PCI_MSI struct list_head msi_list;#endif
Re: [PATCH] x86_32: trim memory by updating e820 v3
drivers/pci/pci-sysfs.c pci_remove_resource_files(struct pci_dev · line 575
Quoted 8 lines · On Tue, 29 Apr 2008 12:37:41 +0200 Ingo Molnar <[email protected]> wrote:
drivers/pci/pci-sysfs.c +8
-0+static int pci_create_attr (struct pci_dev *pdev,int num,int write_combine) +{ +/* allocate attribute structure, piggyback attribute name */ +int name_len = write_combine ?13 :10 ; +struct bin_attribute *res_attr; +int retval; + + res_attr =kzalloc (sizeof (*res_attr) + name_len,GFP_ATOMIC );
That (retained from current code) GFP_ATOMIC cannot be necessary.
Quoted 7 lines
drivers/pci/pci-sysfs.c +7
-0+if (res_attr) { +char *res_attr_name = (char *)(res_attr +1 ); + +if (write_combine) { + pdev->res_attr_wc[num] = res_attr; +sprintf (res_attr_name,"resource%d_wc" , num); + res_attr->mmap = pci_mmap_resource_wc;
drivers/pci/pci-sysfs.c pci_remove_resource_files(struct pci_dev · line 592
Quoted 10 lines
drivers/pci/pci-sysfs.c +10
-0+ }else { + pdev->res_attr[num] = res_attr; +sprintf (res_attr_name,"resource%d" , num); + res_attr->mmap = pci_mmap_resource_uc; + } + res_attr->attr.name = res_attr_name; + res_attr->attr.mode =S_IRUSR |S_IWUSR ; + res_attr->size =pci_resource_len (pdev, num); + res_attr->private = &pdev->resource[num]; + retval =sysfs_create_bin_file (&pdev->dev.kobj, res_attr);
Because of this.
Quoted 5 lines
drivers/pci/pci-sysfs.c +5
-0+ }else + retval = -ENOMEM ; + +return retval; +}
Jesse Barnes
Acked-byRe: [PATCH] x86_32: trim memory by updating e820 v3
In reply to Ingo MolnarQuoted 21 lines · Ingo Molnar
Quoted 8 lines · Jesse Barnes
Quoted 3 lines
i think we should still try to make this a non-default option because modern Xorg should not have any need to touch MTRRs. Perhaps a .config dependent on
CONFIG_DANGEROUS;-)Well, not quite... we're still waiting on some way of getting WC semantics for sysfs PCI files. Suresh tells me something like that is queued up, but until that hits the mainline X will still need to bang the MTRRs to get decent performance.
yes, the patch below is queued up for an eventual v2.6.26 merge. If it looks fine to you, could you please ack it so that we can send it to Linus? I'd like to do this after some pending PAT fixes are upstream.
Ingo
---------------->
Subject: x86, PAT: exportresource_wcin pci sysfs
From: [email protected]
Date: Tue, 18 Mar 2008 17:00:22 -0700
Quoted 6 lines
For the ranges with
IORESOURCE_PREFETCH, export a newresource_wcinterface in pci /sysfs along with resource (which is uncached).Signed-off-by Venkatesh Pallipadi <[email protected]>Signed-off-by Suresh Siddha <[email protected]>Signed-off-by Ingo Molnar <[email protected]>
I really would have preferred a new mmap flag for this like ia64 used to have, but Suresh and Venki tell me that a flag doesn't map very well to what some architectures support, so I suppose a new file is the way to go. Should work fine for X's needs.
Thanks,
Jesse
PATCH 1/1 PCI: export resource_wc in pci sysfs
Quoted 6 lines · Jesse Barnes
I really would have preferred a new mmap flag for this like ia64 used to have, but Suresh and Venki tell me that a flag doesn't map very well to what some architectures support, so I suppose a new file is the way to go. Should work fine for X's needs.
Acked-by Jesse Barnes <[email protected]>
thanks! Linus, please apply the patch below.
Ingo
------------------>
Subject: PCI: export resource_wc in pci sysfs
From: [email protected]
Date: Tue, 18 Mar 2008 17:00:22 -0700
For the ranges with IORESOURCE_PREFETCH, export a new resource_wc interface in pci /sysfs along with resource (which is uncached).
--- Documentation/filesystems/sysfs-pci.txt | 1 drivers/pci/pci-sysfs.c | 82 +++++++++++++++++++++++--------- include/linux/pci.h | 1 3 files changed, 63 insertions(+), 21 deletions(-)
Documentation/filesystems/sysfs-pci.txt +1 -0
@@ -36,6 +36,7 @@ files, each with their own function. local_cpus nearby CPU mask (cpumask, ro) resource PCI resource host addresses (ascii, ro) resource0..N PCI resource N, if present (binary, mmap) + resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap) rom PCI ROM resource, if present (binary, ro) subsystem_device PCI subsystem device (ascii, ro) subsystem_vendor PCI subsystem vendor (ascii, ro)
drivers/pci/pci-sysfs.c +61 -21
121 lines not on this page · raw message
include/linux/pci.h +1 -0
@@ -205,6 +205,7 @@ struct pci_dev {struct bin_attribute *rom_attr;/* attribute descriptor for sysfs ROM entry */ int rom_attr_enabled;/* has display of the rom attribute been enabled? */ struct bin_attribute *res_attr[DEVICE_COUNT_RESOURCE ];/* sysfs file for resources */ +struct bin_attribute *res_attr_wc[DEVICE_COUNT_RESOURCE ];/* sysfs file for WC mapping of resources */ #ifdef CONFIG_PCI_MSI struct list_head msi_list;#endif
Re: [patch] PCI: export resource_wc in pci sysfs
Quoted 20 lines · On Wed, 30 Apr 2008 00:03:46 +0200 Ingo Molnar <[email protected]> wrote:
drivers/pci/pci-sysfs.c +20
-0+static int pci_create_attr (struct pci_dev *pdev,int num,int write_combine) +{ +/* allocate attribute structure, piggyback attribute name */ +int name_len = write_combine ?13 :10 ; +struct bin_attribute *res_attr; +int retval; + + res_attr =kzalloc (sizeof (*res_attr) + name_len,GFP_ATOMIC ); +if (res_attr) { +char *res_attr_name = (char *)(res_attr +1 ); + +if (write_combine) { + pdev->res_attr_wc[num] = res_attr; +sprintf (res_attr_name,"resource%d_wc" , num); + res_attr->mmap = pci_mmap_resource_wc; + }else { + pdev->res_attr[num] = res_attr; +sprintf (res_attr_name,"resource%d" , num); + res_attr->mmap = pci_mmap_resource_uc; + }
drivers/pci/pci-sysfs.c pci_remove_resource_files(struct pci_dev · line 597
Quoted 10 lines
drivers/pci/pci-sysfs.c +10
-0+ res_attr->attr.name = res_attr_name; + res_attr->attr.mode =S_IRUSR |S_IWUSR ; + res_attr->size =pci_resource_len (pdev, num); + res_attr->private = &pdev->resource[num]; + retval =sysfs_create_bin_file (&pdev->dev.kobj, res_attr); + }else + retval = -ENOMEM ; + +return retval; +}
That GFP_ATOMIC should be switched to GFP_KERNEL.
Do we reeeeeeeely need to pull this tack-the-string-onto-the-end-of-the-struct stunt? If we didn't do that, this code could then be taught about kasprintf() and things like that "? 13 : 10" could be thankfully laid to rest.
Re: [PATCH] x86_32: trim memory by updating e820 v3
In reply to Andrew MortonQuoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> wrote:
[PATCH]
x86_32: trim memory by updating e820 v3when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_get_capand use it inearly_cpu_detect, and movemtrr_bp_initearlyneed Justine to test with his special system with bug bios.
Signed-off-by Yinghai Lu <[email protected]>Speaking of mtrr and e820....
Could someone please take a peek at
http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?For some reason we seem to have turned this:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)into this:
Quoted 8 lines
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1which screws up the X server's attempt to map the video memory at
0xd0000000.
can you check if you can set up MTRR mapping in BIOS from Continuous to Discrete?
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 7 lines · Yinghai Lu
Quoted 2 lines · Andrew Morton
Could someone please take a peek at
http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?can you check if you can set up MTRR mapping in BIOS from Continuous to Discrete?
Unfortunately my BIOS offers no advanced settings at all. The only thing I can change is the size of the video memory. But changing this has no effect on the MTRRs.
Regards,
Mika
Re: [PATCH] x86_32: trim memory by updating e820 v3
In reply to Andrew MortonQuoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> wrote:
[PATCH]
x86_32: trim memory by updating e820 v3when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_get_capand use it inearly_cpu_detect, and movemtrr_bp_initearlyneed Justine to test with his special system with bug bios.
Signed-off-by Yinghai Lu <[email protected]>Speaking of mtrr and e820....
Could someone please take a peek at
http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?For some reason we seem to have turned this:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)into this:
Quoted 9 lines
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1which screws up the X server's attempt to map the video memory at
0xd0000000.
the BIOS should have set memhole to 2048MB or 2560M instead of 1033MB
good mtrr should
Quoted 2 lines
reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1
reg01: base=0x100000000 (4096MB), size=2048MB: write-back, count=1
or
Quoted 4 lines
reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=512MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0x140000000 (4096MB), size=512MB: write-back, count=1
so please talk to your HW esp CPU vendor to fix the BIOS problem.
AMD Rev F and Quadcore should get
Quoted 1 line
reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1
or
Quoted 2 lines
reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=512MB: write-back, count=1
because [4G, TOM2) is WB by default.
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 16 lines · Yinghai Lu
Quoted 8 lines
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1which screws up the X server's attempt to map the video memory at
0xd0000000.the BIOS should have set memhole to 2048MB or 2560M instead of 1033MB
good mtrr should
Quoted 2 lines
reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1
reg01: base=0x100000000 (4096MB), size=2048MB: write-back, count=1
Quoted 8 lines
or
Quoted 4 lines
reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=512MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0x140000000 (4096MB), size=512MB: write-back, count=1so please talk to your HW esp CPU vendor to fix the BIOS problem.
This is a Core 2 Duo CPU, so my CPU vendor is Intel. I assume that the relevant people are already reading this, no?
I'm not sure what I'm supposed to do? Write an Email to Intel support, referencing this thread? Doesn't anyone here already know the right people at Intel who could actually do something about this. I think that would be more useful since I doubt an email to Intel support would reach those people...
Regards,
Mika
Re: [PATCH] x86_32: trim memory by updating e820 v3
In reply to Andrew MortonQuoted 38 lines · Andrew Morton
Quoted 11 lines · On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <[email protected]> wrote:
[PATCH]
x86_32: trim memory by updating e820 v3when mtrr is not covering all e820 table, need to trim the ram, need to update e820
reuse some code for
x86_64here need to add
early_get_capand use it inearly_cpu_detect, and movemtrr_bp_initearlyneed Justine to test with his special system with bug bios.
Signed-off-by Yinghai Lu <[email protected]>Speaking of mtrr and e820....
Could someone please take a peek at
http://bugzilla.kernel.org/show_bug.cgi?id=10508 ?For some reason we seem to have turned this:
[ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable)into this:
Quoted 8 lines
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1which screws up the X server's attempt to map the video memory at
0xd0000000.
please try the patch at
http://lkml.org/lkml/2008/4/28/52
with mtrr_chunk_size=1g, and you should get
you should get
Quoted 5 lines
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
YH
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
Hi Yinghai,
Quoted 9 lines · Yinghai Lu
Quoted 8 lines
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1which screws up the X server's attempt to map the video memory at
0xd0000000.
Quoted 12 lines
please try the patch at
http://lkml.org/lkml/2008/4/28/52
with mtrr_chunk_size=1g, and you should get
you should get
Quoted 5 lines
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
Wow, thanks a lot for this patch! It almost works. This is what I get with mtrr_chunk_size=1g:
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg04: base=0x100001000 (4096MB), size= 4KB: write-back, count=1
reg05: base=0x100002000 (4096MB), size= 8KB: write-back, count=1
reg06: base=0x100004000 (4096MB), size= 16KB: write-back, count=1
reg07: base=0x100008000 (4096MB), size= 32KB: write-back, count=1
And this is what I get without mtrr_chunk_size=1g:
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1
reg02: base=0xa0000000 (2560MB), size= 256MB: write-back, count=1
reg03: base=0xb0000000 (2816MB), size= 256MB: write-back, count=1
reg04: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg05: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg06: base=0x100001000 (4096MB), size= 4KB: write-back, count=1
reg07: base=0x100002000 (4096MB), size= 8KB: write-back, count=1
I attached these outputs and the dmesgs to the bug report:
http://bugzilla.kernel.org/show_bug.cgi?id=10508
dmesg with mtrr_chunk_size=1g:
http://bugzilla.kernel.org/attachment.cgi?id=15945
dmesg without mtrr_chunk_size=1g:
http://bugzilla.kernel.org/attachment.cgi?id=15946
There are some warnings in the output:
[ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1023MB of RAM. [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: at /home/mika/src/linux-2.6/arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x118/0x250() [ 0.000000] Modules linked in: [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.25 #5 [ 0.000000] [<c01273af>] warn_on_slowpath+0x5f/0x90 [ 0.000000] [<c03a8f9d>] _spin_unlock_irqrestore+0xd/0x10 [ 0.000000] [<c0127d4a>] release_console_sem+0x1ba/0x1e0 [ 0.000000] [<c01280d8>] vprintk+0x1c8/0x3a0 [ 0.000000] [<c010ebd3>] generic_get_mtrr+0x93/0x100 [ 0.000000] [<c01282cb>] printk+0x1b/0x20 [ 0.000000] [<c05069d8>] mtrr_trim_uncached_memory+0x118/0x250 [ 0.000000] [<c0504292>] setup_arch+0x312/0x590 [ 0.000000] [<c04fd774>] start_kernel+0x64/0x3a0 [ 0.000000] ======================= [ 0.000000] ---[ end trace ca143223eefdc828 ]---
Let me know if there's anything else I can do to help!
Regards,
Mika
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 51 lines · Mika Fischer
Hi Yinghai,
Quoted 9 lines · Yinghai Lu
Quoted 8 lines
reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1
reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1
reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1which screws up the X server's attempt to map the video memory at
0xd0000000.Quoted 12 lines
please try the patch at
http://lkml.org/lkml/2008/4/28/52
with mtrr_chunk_size=1g, and you should get
you should get
Quoted 5 lines
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1Wow, thanks a lot for this patch! It almost works. This is what I get with mtrr_chunk_size=1g:
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg04: base=0x100001000 (4096MB), size= 4KB: write-back, count=1
reg05: base=0x100002000 (4096MB), size= 8KB: write-back, count=1
reg06: base=0x100004000 (4096MB), size= 16KB: write-back, count=1
reg07: base=0x100008000 (4096MB), size= 32KB: write-back, count=1And this is what I get without mtrr_chunk_size=1g:
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1
reg02: base=0xa0000000 (2560MB), size= 256MB: write-back, count=1
reg03: base=0xb0000000 (2816MB), size= 256MB: write-back, count=1
reg04: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg05: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg06: base=0x100001000 (4096MB), size= 4KB: write-back, count=1
reg07: base=0x100002000 (4096MB), size= 8KB: write-back, count=1I attached these outputs and the dmesgs to the bug report:
Quoted 8 lines
http://bugzilla.kernel.org/show_bug.cgi?id=10508
dmesg with mtrr_chunk_size=1g:
http://bugzilla.kernel.org/attachment.cgi?id=15945dmesg without mtrr_chunk_size=1g:
http://bugzilla.kernel.org/attachment.cgi?id=15946
thanks for testing
please check
http://lkml.org/lkml/2008/4/28/115
also, can you try 64bit too?
YH
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 8 lines · Yinghai Lu
Quoted 6 lines
Quoted 6 lines
you should get
Quoted 5 lines
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1please check
http://lkml.org/lkml/2008/4/28/115
OK, this time it worked!
With mtrr_chunk_size=1g:
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
Without mtrr_chunk_size=1g:
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1
reg02: base=0xa0000000 (2560MB), size= 256MB: write-back, count=1
reg03: base=0xb0000000 (2816MB), size= 256MB: write-back, count=1
reg04: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg05: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg06: base=0x100000000 (4096MB), size=1024MB: write-back, count=1
Both seem equivalent and correct.
There are also no warnings anymore in the dmesg output:
With mtrr_chunk_size=1g:
http://bugzilla.kernel.org/attachment.cgi?id=15950
Without mtrr_chunk_size=1g:
http://bugzilla.kernel.org/attachment.cgi?id=15951
Quoted 1 line
also, can you try 64bit too?
I'm not sure how to do this. Can I compile it under 32bit Linux? If not that will be difficult since I don't have space left for a 64bit installation on my hard-drive. Maybe Gabiel C can test 64bit?
Regards,
Mika
Re: [PATCH] x86_32: trim memory by updating e820 v3
Quoted 34 lines · Mika Fischer
Quoted 8 lines · Yinghai Lu
Quoted 6 lines
Quoted 6 lines
you should get
Quoted 5 lines
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1please check
http://lkml.org/lkml/2008/4/28/115OK, this time it worked!
With mtrr_chunk_size=1g:
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1
reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1Without mtrr_chunk_size=1g:
reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1
reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1
reg02: base=0xa0000000 (2560MB), size= 256MB: write-back, count=1
reg03: base=0xb0000000 (2816MB), size= 256MB: write-back, count=1
reg04: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1
reg05: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1
reg06: base=0x100000000 (4096MB), size=1024MB: write-back, count=1Both seem equivalent and correct.
There are also no warnings anymore in the dmesg output:
With mtrr_chunk_size=1g:
http://bugzilla.kernel.org/attachment.cgi?id=15950
Quoted 8 lines
Without mtrr_chunk_size=1g:
http://bugzilla.kernel.org/attachment.cgi?id=15951Quoted 1 line
also, can you try 64bit too?
I'm not sure how to do this. Can I compile it under 32bit Linux? If not that will be difficult since I don't have space left for a 64bit installation on my hard-drive. Maybe Gabiel C can test 64bit?
Yes sure, done already :) I could test 32/64 bit on this box if needed.
Quoted 3 lines
Regards,
Mika
Gabriel
PATCH 1/1 x86_64: update e820 instead of updating end_pfn v3
In reply to a message not in the archive[PATCH] x86_64: update e820 instead of updating end_pfn v3
need to apply after x86_64 check if Tom2 is enabled
when mtrr is not covering all e820 table, need to trim the ram, need to update e820
so we can reuse some code for x86_32.
after we add early_identify_cpu for x86_32, and move mtrr_bp_init early for x86_32
arch/x86/kernel/cpu/mtrr/main.c +18 -8
@@ -624,6 +624,7 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; +#ifdef CONFIG_X86_64 static int disable_mtrr_trim;static int __init disable_mtrr_trim_setup (char *str)
@@ -633,8 +634,6 @@ static int __init disable_mtrr_trim_setu }early_param ("disable_mtrr_trim" , disable_mtrr_trim_setup); -#ifdef CONFIG_X86_64 -/* * Newer AMD K8s and later CPUs have a special magic MSR way to force WB * for memory >4GB. Check for that here.
@@ -644,7 +643,7 @@ early_param("disable_mtrr_trim", disable#define Tom2Enabled (1U << 21)#define Tom2ForceMemTypeWB (1U << 22) -static __init int amd_special_default_mtrr (void ) +static __init int amd_special_default_mtrr (unsigned long end_pfn) {u32 l, h;
@@ -678,10 +677,11 @@ static __init int amd_special_default_mt* memory off the end by adjusting end_pfn, removing it from the kernel's * allocation pools, warning the user with an obnoxious message. */ -void __init mtrr_trim_uncached_memory (void ) +int __init mtrr_trim_uncached_memory (unsigned long end_pfn) {unsigned long i, base, size, highest_addr =0 , def, dummy;mtrr_type type; +u64 trim_start, trim_size;/* * Make sure we only trim uncachable memory on machines that
@@ -690,7 +690,7 @@ void __init mtrr_trim_uncached_memory(vordmsr (MTRRdefType_MSR, def, dummy); def &=0xff ;if (!is_cpu (INTEL ) || disable_mtrr_trim || def !=MTRR_TYPE_UNCACHABLE ) -return ; +return 0 ;/* Find highest cached pfn */ for (i =0 ; i < num_var_ranges; i++) {
@@ -703,8 +703,8 @@ void __init mtrr_trim_uncached_memory(vo highest_addr = base + size; } -if (amd_special_default_mtrr ()) -return ; +if (amd_special_default_mtrr (end_pfn)) +return 0 ;if ((highest_addr >>PAGE_SHIFT ) < end_pfn) {printk (KERN_WARNING "***************\n" );
@@ -713,8 +713,18 @@ void __init mtrr_trim_uncached_memory(vo"memory, trimmed %ld pages\n" , end_pfn - (highest_addr >> PAGE_SHIFT));printk (KERN_WARNING "***************\n" ); - end_pfn = highest_addr >> PAGE_SHIFT; + +printk (KERN_INFO "update e820 for mtrr\n" ); + trim_start = highest_addr; + trim_size = end_pfn; + trim_size <<=PAGE_SHIFT ; + trim_size -= trim_start; +add_memory_region (trim_start, trim_size,E820_RESERVED ); +update_e820 (); + return 1; } + +return 0 ; }#endif
arch/x86/kernel/setup_64.c +5 -2
@@ -324,9 +324,12 @@ void __init setup_arch(char **cmdline_p)* we are rounding upwards: */ end_pfn =e820_end_of_ram (); -/* Trim memory not covered by WB MTRRs */ +/* update e820 for memory not covered by WB MTRRs */ mtrr_bp_init (); -mtrr_trim_uncached_memory (); +if (mtrr_trim_uncached_memory (end_pfn)) { +e820_register_active_regions (0 ,0 ,-1UL ); + end_pfn =e820_end_of_ram (); + } num_physpages = end_pfn;
include/asm-x86/mtrr.h +3 -2
@@ -97,7 +97,7 @@ extern int mtrr_del_page (int reg, unsigextern void mtrr_centaur_report_mcr (int mcr,u32 lo,u32 hi);extern void mtrr_ap_init (void );extern void mtrr_bp_init (void ); -extern void mtrr_trim_uncached_memory (void ); +extern int mtrr_trim_uncached_memory (unsigned long end_pfn);# else #define mtrr_save_fixed_ranges (arg) do {} while (0)#define mtrr_save_state () do {} while (0)
@@ -121,8 +121,9 @@ static __inline__ int mtrr_del_page (int {return -ENODEV ; } -static __inline__void mtrr_trim_uncached_memory (void ) +static __inline__int mtrr_trim_uncached_memory (unsigned long end_pfn) { +return 0 ; }static __inline__void mtrr_centaur_report_mcr (int mcr,u32 lo,u32 hi) {;}