* [PATCH] x86: disable_mtrr_trim only need for x86_64 @ 2008-01-20 4:45 Yinghai Lu 2008-01-20 5:37 ` H. Peter Anvin [not found] ` <200801202255.02645.yinghai.lu@sun.com> 0 siblings, 2 replies; 87+ messages in thread From: Yinghai Lu @ 2008-01-20 4:45 UTC (permalink / raw) To: Ingo Molnar; +Cc: Andi Kleen, LKML, Jesse Barnes, Andrew Morton [PATCH] x86: disable_mtrr_trim only need for x86_64 mtrr_trim_uncached_memory is only used in x86_64, so disable_mtrr_trim is not needed for x86_32 Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c index 46763e3..608c88a 100644 --- a/arch/x86/kernel/cpu/mtrr/main.c +++ b/arch/x86/kernel/cpu/mtrr/main.c @@ -624,6 +624,7 @@ static struct sysdev_driver mtrr_sysdev_driver = { .resume = mtrr_restore, }; +#ifdef CONFIG_X86_64 static int disable_mtrr_trim; static int __init disable_mtrr_trim_setup(char *str) @@ -633,7 +634,6 @@ static int __init disable_mtrr_trim_setup(char *str) } early_param("disable_mtrr_trim", disable_mtrr_trim_setup); -#ifdef CONFIG_X86_64 /** * mtrr_trim_uncached_memory - trim RAM not covered by MTRRs * ^ permalink raw reply related [flat|nested] 87+ messages in thread
* Re: [PATCH] x86: disable_mtrr_trim only need for x86_64 2008-01-20 4:45 [PATCH] x86: disable_mtrr_trim only need for x86_64 Yinghai Lu @ 2008-01-20 5:37 ` H. Peter Anvin 2008-01-20 6:55 ` Yinghai Lu 2008-01-20 8:17 ` [PATCH] x86_64: update e820 instead of updating end_pfn Yinghai Lu [not found] ` <200801202255.02645.yinghai.lu@sun.com> 1 sibling, 2 replies; 87+ messages in thread From: H. Peter Anvin @ 2008-01-20 5:37 UTC (permalink / raw) To: Yinghai Lu; +Cc: Ingo Molnar, Andi Kleen, LKML, Jesse Barnes, Andrew Morton Yinghai Lu wrote: > [PATCH] x86: disable_mtrr_trim only need for x86_64 > > mtrr_trim_uncached_memory is only used in x86_64, > > so disable_mtrr_trim is not needed for x86_32 > > Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> That seems like a bug, and if so this patch goes the wrong direction. (If the 32-bit code has another solution for the same problem, they should be unified.) The trimming of uncachable memory affects both 32- and 64-bit kernels; it's the same hardware, and even 32-bit kernels (with PAE) can access memory above 4 GB. -hpa ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86: disable_mtrr_trim only need for x86_64 2008-01-20 5:37 ` H. Peter Anvin @ 2008-01-20 6:55 ` Yinghai Lu 2008-01-20 8:17 ` [PATCH] x86_64: update e820 instead of updating end_pfn Yinghai Lu 1 sibling, 0 replies; 87+ messages in thread From: Yinghai Lu @ 2008-01-20 6:55 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Ingo Molnar, Andi Kleen, LKML, Jesse Barnes, Andrew Morton On Jan 19, 2008 9:37 PM, H. Peter Anvin <hpa@zytor.com> wrote: > Yinghai Lu wrote: > > [PATCH] x86: disable_mtrr_trim only need for x86_64 > > > > mtrr_trim_uncached_memory is only used in x86_64, > > > > so disable_mtrr_trim is not needed for x86_32 > > > > Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> > > That seems like a bug, and if so this patch goes the wrong direction. > (If the 32-bit code has another solution for the same problem, they > should be unified.) > > The trimming of uncachable memory affects both 32- and 64-bit kernels; > it's the same hardware, and even 32-bit kernels (with PAE) can access > memory above 4 GB. > the trim fix for x86_64 is update end_pfn, and use that as max_pfn, and max_low_pfn in setup_arch. but i386 is setup_arch is only using max_low_pfn. to make you happy, the simple way is update e820 table so code could be unified between i386 and x86_64 update the e820 table by checking mtrr like checking gart hole... is that OK? YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH] x86_64: update e820 instead of updating end_pfn 2008-01-20 5:37 ` H. Peter Anvin 2008-01-20 6:55 ` Yinghai Lu @ 2008-01-20 8:17 ` Yinghai Lu 2008-01-20 9:20 ` Ingo Molnar 1 sibling, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-01-20 8:17 UTC (permalink / raw) To: H. Peter Anvin, Ingo Molnar; +Cc: Andi Kleen, LKML, Jesse Barnes, Andrew Morton [PATCH] x86_64: update e820 instead of updating end_pfn when mtrr is not covering all e820 table, need to trim the ram, need to update e820 so we can reuse some code for x86_32. need to add early_identify_cpu for x86_32, and move mtrr_bp_init early Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c index 46763e3..28ae79a 100644 --- a/arch/x86/kernel/cpu/mtrr/main.c +++ b/arch/x86/kernel/cpu/mtrr/main.c @@ -644,16 +644,17 @@ early_param("disable_mtrr_trim", disable_mtrr_trim_setup); * it from the kernel's allocation pools, warning the user with an obnoxious * message. */ -void __init mtrr_trim_uncached_memory(void) +int __init mtrr_trim_uncached_memory(unsigned long end_pfn) { unsigned long i, base, size, highest_addr = 0, def, dummy; mtrr_type type; + u64 trim_start, trim_size; /* Make sure we only trim uncachable memory on Intel machines */ rdmsr(MTRRdefType_MSR, def, dummy); def &= 0xff; if (!is_cpu(INTEL) || disable_mtrr_trim || def != MTRR_TYPE_UNCACHABLE) - return; + return 0; /* Find highest cached pfn */ for (i = 0; i < num_var_ranges; i++) { @@ -673,8 +674,18 @@ void __init mtrr_trim_uncached_memory(void) "memory, trimmed %ld pages\n", end_pfn - (highest_addr >> PAGE_SHIFT)); printk(KERN_WARNING "***************\n"); - end_pfn = highest_addr >> PAGE_SHIFT; + + printk(KERN_INFO "update e820 for mtrr\n"); + trim_start = highest_addr; + trim_size = end_pfn; + trim_size <<= PAGE_SHIFT; + trim_size -= trim_start; + add_memory_region(trim_start, trim_size, E820_RESERVED); + update_e820(); + return 1; } + + return 0; } #endif diff --git a/arch/x86/kernel/setup_64.c b/arch/x86/kernel/setup_64.c index 2ad8bdd..5194c2a 100644 --- a/arch/x86/kernel/setup_64.c +++ b/arch/x86/kernel/setup_64.c @@ -324,9 +324,12 @@ void __init setup_arch(char **cmdline_p) * we are rounding upwards: */ end_pfn = e820_end_of_ram(); - /* Trim memory not covered by WB MTRRs */ + /* update e820 for memory not covered by WB MTRRs */ mtrr_bp_init(); - mtrr_trim_uncached_memory(); + if (mtrr_trim_uncached_memory(end_pfn)) { + e820_register_active_regions(0, 0, -1UL); + end_pfn = e820_end_of_ram(); + } num_physpages = end_pfn; diff --git a/include/asm-x86/mtrr.h b/include/asm-x86/mtrr.h index 96876ec..e552503 100644 --- a/include/asm-x86/mtrr.h +++ b/include/asm-x86/mtrr.h @@ -97,7 +97,7 @@ extern int mtrr_del_page (int reg, unsigned long base, unsigned long size); extern void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi); extern void mtrr_ap_init(void); extern void mtrr_bp_init(void); -extern void mtrr_trim_uncached_memory(void); +extern int mtrr_trim_uncached_memory(unsigned long end_pfn); # else #define mtrr_save_fixed_ranges(arg) do {} while (0) #define mtrr_save_state() do {} while (0) @@ -121,8 +121,9 @@ static __inline__ int mtrr_del_page (int reg, unsigned long base, { return -ENODEV; } -static __inline__ void mtrr_trim_uncached_memory(void) +static __inline__ int mtrr_trim_uncached_memory(unsigned long end_pfn) { + return 0; } static __inline__ void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi) {;} ^ permalink raw reply related [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: update e820 instead of updating end_pfn 2008-01-20 8:17 ` [PATCH] x86_64: update e820 instead of updating end_pfn Yinghai Lu @ 2008-01-20 9:20 ` Ingo Molnar 2008-01-20 15:08 ` Andi Kleen 2008-01-21 0:00 ` [PATCH] x86_64: update e820 instead of updating end_pfn Yinghai Lu 0 siblings, 2 replies; 87+ messages in thread From: Ingo Molnar @ 2008-01-20 9:20 UTC (permalink / raw) To: Yinghai Lu; +Cc: H. Peter Anvin, Andi Kleen, LKML, Jesse Barnes, Andrew Morton * Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: > [PATCH] x86_64: update e820 instead of updating end_pfn > > when mtrr is not covering all e820 table, need to trim the ram, need > to update e820 ok, i like this approach even more - applied. Would you like to have a shot at adding mtrr_trim_uncached_memory() to 32-bit too? It is affected by the same problem (if not more). Ingo ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: update e820 instead of updating end_pfn 2008-01-20 9:20 ` Ingo Molnar @ 2008-01-20 15:08 ` Andi Kleen 2008-01-21 5:40 ` [PATCH] x86_64: update e820 instead of updating end_pfn v2 Yinghai Lu 2008-01-21 0:00 ` [PATCH] x86_64: update e820 instead of updating end_pfn Yinghai Lu 1 sibling, 1 reply; 87+ messages in thread From: Andi Kleen @ 2008-01-20 15:08 UTC (permalink / raw) To: Ingo Molnar; +Cc: Yinghai Lu, H. Peter Anvin, LKML, Jesse Barnes, Andrew Morton On Sunday 20 January 2008 10:20:27 Ingo Molnar wrote: > * Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: > > [PATCH] x86_64: update e820 instead of updating end_pfn > > > > when mtrr is not covering all e820 table, need to trim the ram, need > > to update e820 > > ok, i like this approach even more - applied. Would you like to have a > shot at adding mtrr_trim_uncached_memory() to 32-bit too? It is affected > by the same problem (if not more). What about the AMD fix I posted? You ignored that one for now but it is far more critical because it makes these patches break any modern AMD machine with >3GB. -Andi ^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH] x86_64: update e820 instead of updating end_pfn v2 2008-01-20 15:08 ` Andi Kleen @ 2008-01-21 5:40 ` Yinghai Lu 2008-01-21 5:44 ` [PATCH] x86_32: trim memory by updating e820 Yinghai Lu 2008-01-21 5:58 ` [PATCH] x86_64: update e820 instead of updating end_pfn v2 Andi Kleen 0 siblings, 2 replies; 87+ messages in thread From: Yinghai Lu @ 2008-01-21 5:40 UTC (permalink / raw) To: Ingo Molnar; +Cc: Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, Andrew Morton [PATCH] x86_64: update e820 instead of updating end_pfn v2 need to be applied after andi's patch for AMD tom2 wb check when mtrr is not covering all e820 table, need to trim the ram, need to update e820 so we can reuse some code for x86_32. need to add early_identify_cpu for x86_32, and move mtrr_bp_init early Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c +++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c @@ -624,6 +624,7 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; +#ifdef CONFIG_X86_64 static int disable_mtrr_trim; static int __init disable_mtrr_trim_setup(char *str) @@ -633,17 +634,16 @@ static int __init disable_mtrr_trim_setu } early_param("disable_mtrr_trim", disable_mtrr_trim_setup); -#ifdef CONFIG_X86_64 - /* * Newer AMD K8s and later CPUs have a special magic MSR way to force WB * for memory >4GB. Check for that here. * Note this won't check if the MTRRs < 4GB where the magic bit doesn't * apply to are wrong, but so far we don't know of any such case in the wild. */ +#define Tom2Enabled (1U << 21) #define Tom2ForceMemTypeWB (1U << 22) -static __init int amd_special_default_mtrr(void) +static __init int amd_special_default_mtrr(unsigned long end_pfn) { u32 l, h; @@ -661,8 +661,9 @@ static __init int amd_special_default_mt * Memory between 4GB and top of mem is forced WB by this magic bit. * Reserved before K8RevF, but should be zero there. */ - if (l & Tom2ForceMemTypeWB) - return 1; + if (l & Tom2Enabled) + if (l & Tom2ForceMemTypeWB) + return 1; return 0; } @@ -676,10 +677,11 @@ static __init int amd_special_default_mt * memory off the end by adjusting end_pfn, removing it from the kernel's * allocation pools, warning the user with an obnoxious message. */ -void __init mtrr_trim_uncached_memory(void) +int __init mtrr_trim_uncached_memory(unsigned long end_pfn) { unsigned long i, base, size, highest_addr = 0, def, dummy; mtrr_type type; + u64 trim_start, trim_size; /* * Make sure we only trim uncachable memory on machines that @@ -688,7 +690,7 @@ void __init mtrr_trim_uncached_memory(vo rdmsr(MTRRdefType_MSR, def, dummy); def &= 0xff; if (!is_cpu(INTEL) || disable_mtrr_trim || def != MTRR_TYPE_UNCACHABLE) - return; + return 0; /* Find highest cached pfn */ for (i = 0; i < num_var_ranges; i++) { @@ -701,8 +703,8 @@ void __init mtrr_trim_uncached_memory(vo highest_addr = base + size; } - if (amd_special_default_mtrr()) - return; + if (amd_special_default_mtrr(end_pfn)) + return 0; if ((highest_addr >> PAGE_SHIFT) < end_pfn) { printk(KERN_WARNING "***************\n"); @@ -711,8 +713,18 @@ void __init mtrr_trim_uncached_memory(vo "memory, trimmed %ld pages\n", end_pfn - (highest_addr >> PAGE_SHIFT)); printk(KERN_WARNING "***************\n"); - end_pfn = highest_addr >> PAGE_SHIFT; + + printk(KERN_INFO "update e820 for mtrr\n"); + trim_start = highest_addr; + trim_size = end_pfn; + trim_size <<= PAGE_SHIFT; + trim_size -= trim_start; + add_memory_region(trim_start, trim_size, E820_RESERVED); + update_e820(); + return 1; } + + return 0; } #endif Index: linux-2.6/arch/x86/kernel/setup_64.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/setup_64.c +++ linux-2.6/arch/x86/kernel/setup_64.c @@ -324,9 +324,12 @@ void __init setup_arch(char **cmdline_p) * we are rounding upwards: */ end_pfn = e820_end_of_ram(); - /* Trim memory not covered by WB MTRRs */ + /* update e820 for memory not covered by WB MTRRs */ mtrr_bp_init(); - mtrr_trim_uncached_memory(); + if (mtrr_trim_uncached_memory(end_pfn)) { + e820_register_active_regions(0, 0, -1UL); + end_pfn = e820_end_of_ram(); + } num_physpages = end_pfn; Index: linux-2.6/include/asm-x86/mtrr.h =================================================================== --- linux-2.6.orig/include/asm-x86/mtrr.h +++ linux-2.6/include/asm-x86/mtrr.h @@ -97,7 +97,7 @@ extern int mtrr_del_page (int reg, unsig extern void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi); extern void mtrr_ap_init(void); extern void mtrr_bp_init(void); -extern void mtrr_trim_uncached_memory(void); +extern int mtrr_trim_uncached_memory(unsigned long end_pfn); # else #define mtrr_save_fixed_ranges(arg) do {} while (0) #define mtrr_save_state() do {} while (0) @@ -121,8 +121,9 @@ static __inline__ int mtrr_del_page (int { return -ENODEV; } -static __inline__ void mtrr_trim_uncached_memory(void) +static __inline__ int mtrr_trim_uncached_memory(unsigned long end_pfn) { + return 0; } static __inline__ void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi) {;} ^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH] x86_32: trim memory by updating e820 2008-01-21 5:40 ` [PATCH] x86_64: update e820 instead of updating end_pfn v2 Yinghai Lu @ 2008-01-21 5:44 ` Yinghai Lu 2008-01-21 5:58 ` [PATCH] x86_64: update e820 instead of updating end_pfn v2 Andi Kleen 1 sibling, 0 replies; 87+ messages in thread From: Yinghai Lu @ 2008-01-21 5:44 UTC (permalink / raw) To: Ingo Molnar, H. Peter Anvin; +Cc: Andi Kleen, LKML, Jesse Barnes, Andrew Morton [PATCH] x86_32: trim memory by updating e820 need to be applied after the patch for x86_64 version mtrr fix e820 v2. when mtrr is not covering all e820 table, need to trim the ram, need to update e820 reuse some code for x86_64 here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early compiled only, need someone test it. Index: linux-2.6/arch/x86/kernel/cpu/common.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/common.c +++ linux-2.6/arch/x86/kernel/cpu/common.c @@ -396,11 +396,9 @@ __setup("serialnumber", x86_serial_nr_se /* * This does the hard work of actually picking apart the CPU stuff... */ -void __cpuinit identify_cpu(struct cpuinfo_x86 *c) +void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c) { - int i; - c->loops_per_jiffy = loops_per_jiffy; c->x86_cache_size = -1; c->x86_vendor = X86_VENDOR_UNKNOWN; c->cpuid_level = -1; /* CPUID not detected */ @@ -424,7 +422,14 @@ void __cpuinit identify_cpu(struct cpuin if (this_cpu->c_identify) this_cpu->c_identify(c); +} +void __cpuinit identify_cpu(struct cpuinfo_x86 *c) +{ + int i; + + c->loops_per_jiffy = loops_per_jiffy; + early_identify_cpu(c); /* * Vendor-specific initialization. In this section we * canonicalize the feature flags, meaning if there are @@ -485,7 +490,6 @@ void __init identify_boot_cpu(void) identify_cpu(&boot_cpu_data); sysenter_setup(); enable_sep_cpu(); - mtrr_bp_init(); } void __cpuinit identify_secondary_cpu(struct cpuinfo_x86 *c) Index: linux-2.6/arch/x86/kernel/setup_32.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/setup_32.c +++ linux-2.6/arch/x86/kernel/setup_32.c @@ -49,6 +49,7 @@ #include <video/edid.h> +#include <asm/mtrr.h> #include <asm/apic.h> #include <asm/e820.h> #include <asm/mpspec.h> @@ -747,6 +748,7 @@ void __init setup_arch(char **cmdline_p) bss_resource.start = virt_to_phys(&__bss_start); bss_resource.end = virt_to_phys(&__bss_stop)-1; + early_identify_cpu(&boot_cpu_data); parse_early_param(); if (user_defined_memmap) { @@ -762,6 +764,12 @@ void __init setup_arch(char **cmdline_p) max_low_pfn = setup_memory(); + /* update e820 for memory not covered by WB MTRRs */ + mtrr_bp_init(); + if (mtrr_trim_uncached_memory(max_pfn)) { + max_low_pfn = setup_memory(); + } + #ifdef CONFIG_VMI /* * Must be after max_low_pfn is determined, and before kernel Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c +++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c @@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; -#ifdef CONFIG_X86_64 static int disable_mtrr_trim; static int __init disable_mtrr_trim_setup(char *str) @@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(uns return 0; } -#endif /** * mtrr_bp_init - initialize mtrrs on the boot CPU Index: linux-2.6/Documentation/kernel-parameters.txt =================================================================== --- linux-2.6.orig/Documentation/kernel-parameters.txt +++ linux-2.6/Documentation/kernel-parameters.txt @@ -575,7 +575,7 @@ and is between 256 and 4096 characters. See drivers/char/README.epca and Documentation/digiepca.txt. - disable_mtrr_trim [X86-64, Intel only] + disable_mtrr_trim [X86, Intel and AMD only] By default the kernel will trim any uncacheable memory out of your available memory pool based on MTRR settings. This parameter disables that behavior, Index: linux-2.6/include/asm-x86/processor.h =================================================================== --- linux-2.6.orig/include/asm-x86/processor.h +++ linux-2.6/include/asm-x86/processor.h @@ -131,6 +131,7 @@ DECLARE_PER_CPU(struct cpuinfo_x86, cpu_ void cpu_detect(struct cpuinfo_x86 *c); +extern void early_identify_cpu(struct cpuinfo_x86 *); extern void identify_cpu(struct cpuinfo_x86 *); extern void identify_boot_cpu(void); extern void identify_secondary_cpu(struct cpuinfo_x86 *); Index: linux-2.6/arch/x86/kernel/e820_32.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/e820_32.c +++ linux-2.6/arch/x86/kernel/e820_32.c @@ -827,3 +827,14 @@ static int __init parse_memmap(char *arg return 0; } early_param("memmap", parse_memmap); +void __init update_e820(void) +{ + u8 nr_map; + + nr_map = e820.nr_map; + if (sanitize_e820_map(e820.map, &nr_map)) + return; + e820.nr_map = nr_map; + printk(KERN_INFO "modified physical RAM map:\n"); + print_memory_map("modified"); +} Index: linux-2.6/include/asm-x86/e820_32.h =================================================================== --- linux-2.6.orig/include/asm-x86/e820_32.h +++ linux-2.6/include/asm-x86/e820_32.h @@ -19,6 +19,7 @@ #ifndef __ASSEMBLY__ extern struct e820map e820; +extern void update_e820(void); extern int e820_all_mapped(u64 start, u64 end, unsigned type); extern int e820_any_mapped(u64 start, u64 end, unsigned type); @@ -29,6 +30,8 @@ extern int is_memory_all_valid(u64 start extern int is_memory_all_reserved(u64 start, u64 end); extern void find_max_pfn(void); extern void register_bootmem_low_pages(unsigned long max_low_pfn); +extern void add_memory_region(unsigned long long start, + unsigned long long size, int type); extern void e820_register_memory(void); extern void limit_regions(unsigned long long size); extern void print_memory_map(char *who); ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: update e820 instead of updating end_pfn v2 2008-01-21 5:40 ` [PATCH] x86_64: update e820 instead of updating end_pfn v2 Yinghai Lu 2008-01-21 5:44 ` [PATCH] x86_32: trim memory by updating e820 Yinghai Lu @ 2008-01-21 5:58 ` Andi Kleen 2008-01-21 6:05 ` Harvey Harrison 2008-01-21 6:57 ` [PATCH] x86_64: check if Tom2 is enabled Yinghai Lu 1 sibling, 2 replies; 87+ messages in thread From: Andi Kleen @ 2008-01-21 5:58 UTC (permalink / raw) To: Yinghai Lu; +Cc: Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Andrew Morton > { > u32 l, h; > > @@ -661,8 +661,9 @@ static __init int amd_special_default_mt > * Memory between 4GB and top of mem is forced WB by this magic bit. > * Reserved before K8RevF, but should be zero there. > */ > - if (l & Tom2ForceMemTypeWB) > - return 1; > + if (l & Tom2Enabled) > + if (l & Tom2ForceMemTypeWB) > + return 1; That change is good agreed, but I would suggest to put it into a separate patch with a description -Andi ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: update e820 instead of updating end_pfn v2 2008-01-21 5:58 ` [PATCH] x86_64: update e820 instead of updating end_pfn v2 Andi Kleen @ 2008-01-21 6:05 ` Harvey Harrison 2008-01-21 6:08 ` Andi Kleen 2008-01-21 6:57 ` [PATCH] x86_64: check if Tom2 is enabled Yinghai Lu 1 sibling, 1 reply; 87+ messages in thread From: Harvey Harrison @ 2008-01-21 6:05 UTC (permalink / raw) To: Andi Kleen Cc: Yinghai Lu, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Andrew Morton On Mon, 2008-01-21 at 06:58 +0100, Andi Kleen wrote: > > { > > u32 l, h; > > > > @@ -661,8 +661,9 @@ static __init int amd_special_default_mt > > * Memory between 4GB and top of mem is forced WB by this magic bit. > > * Reserved before K8RevF, but should be zero there. > > */ > > - if (l & Tom2ForceMemTypeWB) > > - return 1; > > + if (l & Tom2Enabled) > > + if (l & Tom2ForceMemTypeWB) > > + return 1; > > That change is good agreed, but I would suggest to put it into a separate > patch with a description > Perhaps like this: if (l & (Tom2Enabled|Tom2ForceMemTypeWB)) return 1; Harvey ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: update e820 instead of updating end_pfn v2 2008-01-21 6:05 ` Harvey Harrison @ 2008-01-21 6:08 ` Andi Kleen 2008-01-21 6:14 ` Li Zefan 0 siblings, 1 reply; 87+ messages in thread From: Andi Kleen @ 2008-01-21 6:08 UTC (permalink / raw) To: Harvey Harrison Cc: Yinghai Lu, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Andrew Morton > > 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: update e820 instead of updating end_pfn v2 2008-01-21 6:08 ` Andi Kleen @ 2008-01-21 6:14 ` Li Zefan 0 siblings, 0 replies; 87+ messages in thread From: Li Zefan @ 2008-01-21 6:14 UTC (permalink / raw) To: Andi Kleen Cc: Harvey Harrison, Yinghai Lu, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Andrew Morton Andi Kleen wrote: >>> That change is good agreed, but I would suggest to put it into a separate >>> patch with a description >>> >> Perhaps like this: >> >> if (l & (Tom2Enabled|Tom2ForceMemTypeWB)) >> return 1; > > That's not equivalent. > > -Andi > The equivalence is: if ((1 & Tom2Enabled) && (1 & Tom2ForceMemTypeWB)) return 1; ^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH] x86_64: check if Tom2 is enabled 2008-01-21 5:58 ` [PATCH] x86_64: update e820 instead of updating end_pfn v2 Andi Kleen 2008-01-21 6:05 ` Harvey Harrison @ 2008-01-21 6:57 ` Yinghai Lu 2008-01-21 17:24 ` Cyrill Gorcunov 1 sibling, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-01-21 6:57 UTC (permalink / raw) To: Andi Kleen, Ingo Molnar; +Cc: H. Peter Anvin, LKML, Jesse Barnes, Andrew Morton [PATCH] x86_64: check if Tom2 is enabled need to applied after andi's amd special tom2 wb check patch in amd_special_default_mtrr need to check if TOM2 is enabled Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c index 289ba1a..26eed57 100644 --- a/arch/x86/kernel/cpu/mtrr/main.c +++ b/arch/x86/kernel/cpu/mtrr/main.c @@ -641,6 +641,7 @@ early_param("disable_mtrr_trim", disable_mtrr_trim_setup); * Note this won't check if the MTRRs < 4GB where the magic bit doesn't * apply to are wrong, but so far we don't know of any such case in the wild. */ +#define Tom2Enabled (1U << 21) #define Tom2ForceMemTypeWB (1U << 22) static __init int amd_special_default_mtrr(void) @@ -661,7 +662,8 @@ static __init int amd_special_default_mtrr(void) * Memory between 4GB and top of mem is forced WB by this magic bit. * Reserved before K8RevF, but should be zero there. */ - if (l & Tom2ForceMemTypeWB) + if ((l & (Tom2Enabled | Tom2ForceMemTypeWB)) == + (Tom2Enabled | Tom2ForceMemTypeWB)) return 1; return 0; } ^ permalink raw reply related [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: check if Tom2 is enabled 2008-01-21 6:57 ` [PATCH] x86_64: check if Tom2 is enabled Yinghai Lu @ 2008-01-21 17:24 ` Cyrill Gorcunov 2008-01-21 17:39 ` H. Peter Anvin 2008-01-21 18:03 ` Andi Kleen 0 siblings, 2 replies; 87+ messages in thread From: Cyrill Gorcunov @ 2008-01-21 17:24 UTC (permalink / raw) To: Yinghai Lu Cc: Andi Kleen, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Andrew Morton [Yinghai Lu - Sun, Jan 20, 2008 at 10:57:46PM -0800] | [PATCH] x86_64: check if Tom2 is enabled | | need to applied after andi's amd special tom2 wb check patch | | in amd_special_default_mtrr need to check if TOM2 is enabled | | Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> | | diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c | index 289ba1a..26eed57 100644 | --- a/arch/x86/kernel/cpu/mtrr/main.c | +++ b/arch/x86/kernel/cpu/mtrr/main.c | @@ -641,6 +641,7 @@ early_param("disable_mtrr_trim", disable_mtrr_trim_setup); | * Note this won't check if the MTRRs < 4GB where the magic bit doesn't | * apply to are wrong, but so far we don't know of any such case in the wild. | */ | +#define Tom2Enabled (1U << 21) | #define Tom2ForceMemTypeWB (1U << 22) | | static __init int amd_special_default_mtrr(void) | @@ -661,7 +662,8 @@ static __init int amd_special_default_mtrr(void) | * Memory between 4GB and top of mem is forced WB by this magic bit. | * Reserved before K8RevF, but should be zero there. | */ | - if (l & Tom2ForceMemTypeWB) | + if ((l & (Tom2Enabled | Tom2ForceMemTypeWB)) == | + (Tom2Enabled | Tom2ForceMemTypeWB)) | return 1; | return 0; | } is it possible to change 'l' and 'h' to 'low' and 'high'? 'cause 'l' does look like '1' (one) number... - Cyrill - ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: check if Tom2 is enabled 2008-01-21 17:24 ` Cyrill Gorcunov @ 2008-01-21 17:39 ` H. Peter Anvin 2008-01-21 17:49 ` Cyrill Gorcunov 2008-01-21 18:03 ` Andi Kleen 1 sibling, 1 reply; 87+ messages in thread From: H. Peter Anvin @ 2008-01-21 17:39 UTC (permalink / raw) To: Cyrill Gorcunov Cc: Yinghai Lu, Andi Kleen, Ingo Molnar, LKML, Jesse Barnes, Andrew Morton Cyrill Gorcunov wrote: > > is it possible to change 'l' and 'h' to 'low' and 'high'? > 'cause 'l' does look like '1' (one) number... > I think you should use a different font. Otherwise we're soon in a position where we can't abbreviate anything that starts with L and keep using lower case throughout. That doesn't seem like a valid tradeoff to me. There are plenty of fonts which have good visual distinction between l and 1 and O and 0. -hpa ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: check if Tom2 is enabled 2008-01-21 17:39 ` H. Peter Anvin @ 2008-01-21 17:49 ` Cyrill Gorcunov 0 siblings, 0 replies; 87+ messages in thread From: Cyrill Gorcunov @ 2008-01-21 17:49 UTC (permalink / raw) To: H. Peter Anvin Cc: Yinghai Lu, Andi Kleen, Ingo Molnar, LKML, Jesse Barnes, Andrew Morton [H. Peter Anvin - Mon, Jan 21, 2008 at 09:39:16AM -0800] > Cyrill Gorcunov wrote: >> is it possible to change 'l' and 'h' to 'low' and 'high'? >> 'cause 'l' does look like '1' (one) number... > > I think you should use a different font. Otherwise we're soon in a > position where we can't abbreviate anything that starts with L and keep > using lower case throughout. That doesn't seem like a valid tradeoff to > me. > > There are plenty of fonts which have good visual distinction between l and > 1 and O and 0. > > -hpa > Hi Peter, of course you're right!!! but... actually the only several symbols affected on this: 1-l, O-0 (maybe a few more, dunno) and that is the case for one-letter-ID only and that is so easy to avoid a such situation. Anyway - as you wish ;) - Cyrill - ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: check if Tom2 is enabled 2008-01-21 17:24 ` Cyrill Gorcunov 2008-01-21 17:39 ` H. Peter Anvin @ 2008-01-21 18:03 ` Andi Kleen 2008-01-21 18:09 ` Cyrill Gorcunov 1 sibling, 1 reply; 87+ messages in thread From: Andi Kleen @ 2008-01-21 18:03 UTC (permalink / raw) To: Cyrill Gorcunov Cc: Yinghai Lu, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Andrew Morton > 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 ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: check if Tom2 is enabled 2008-01-21 18:03 ` Andi Kleen @ 2008-01-21 18:09 ` Cyrill Gorcunov 2008-01-21 18:15 ` H. Peter Anvin 0 siblings, 1 reply; 87+ messages in thread From: Cyrill Gorcunov @ 2008-01-21 18:09 UTC (permalink / raw) To: Andi Kleen Cc: Yinghai Lu, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Andrew Morton [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 - ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: check if Tom2 is enabled 2008-01-21 18:09 ` Cyrill Gorcunov @ 2008-01-21 18:15 ` H. Peter Anvin 2008-01-21 18:46 ` Andi Kleen 0 siblings, 1 reply; 87+ messages in thread From: H. Peter Anvin @ 2008-01-21 18:15 UTC (permalink / raw) To: Cyrill Gorcunov Cc: Andi Kleen, Yinghai Lu, Ingo Molnar, LKML, Jesse Barnes, Andrew Morton Cyrill Gorcunov wrote: > [Andi Kleen - Mon, Jan 21, 2008 at 07:03:27PM +0100] > | > | > is it possible to change 'l' and 'h' to 'low' and 'high'? > | > 'cause 'l' does look like '1' (one) number... > | > | It would be fine for me for someone to implement safe_rdtscll() and get rid > | of l and h everywhere. IMHO all the l and h accesses of MSRs are just harder > | to read and error prone over the ll 64bit variants. > | > | But I didn't want to add it just for this. > | > > clear enough, thanks > Actually, I think it depends on the specific MSR - some use the halves for different data, whereas others treat it as a large 64-bit object. Ironically enough, the way the MSR interfaces were carried into the 64-bit world makes the situation worse on 64 bits; edx:eax is the common way to represent a 64-bit value on 32 bits. -hpa ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: check if Tom2 is enabled 2008-01-21 18:15 ` H. Peter Anvin @ 2008-01-21 18:46 ` Andi Kleen 0 siblings, 0 replies; 87+ messages in thread From: Andi Kleen @ 2008-01-21 18:46 UTC (permalink / raw) To: H. Peter Anvin Cc: Cyrill Gorcunov, Yinghai Lu, Ingo Molnar, LKML, Jesse Barnes, Andrew Morton > > Actually, I think it depends on the specific MSR - some use the halves > for different data, whereas others treat it as a large 64-bit object. Even if there are different fields in there it is still much cleaner and simpler if there is only a single number to manipulate. > Ironically enough, the way the MSR interfaces were carried into the > 64-bit world makes the situation worse on 64 bits; edx:eax is the common > way to represent a 64-bit value on 32 bits. It's merely an implementation detail of the instruction. But even on 32bit there is about zero reason to expose that to C code. rdmsr/wrmsr et.al. should have been defined as 64bit only interface in Linux from day zero. -Andi ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_64: update e820 instead of updating end_pfn 2008-01-20 9:20 ` Ingo Molnar 2008-01-20 15:08 ` Andi Kleen @ 2008-01-21 0:00 ` Yinghai Lu 1 sibling, 0 replies; 87+ messages in thread From: Yinghai Lu @ 2008-01-21 0:00 UTC (permalink / raw) To: Ingo Molnar; +Cc: H. Peter Anvin, Andi Kleen, LKML, Jesse Barnes, Andrew Morton On Jan 20, 2008 1:20 AM, Ingo Molnar <mingo@elte.hu> wrote: > > * Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: > > > [PATCH] x86_64: update e820 instead of updating end_pfn > > > > when mtrr is not covering all e820 table, need to trim the ram, need > > to update e820 > > ok, i like this approach even more - applied. Would you like to have a > shot at adding mtrr_trim_uncached_memory() to 32-bit too? It is affected > by the same problem (if not more). for 32 bit, it could use the same mtrr_trim_uncached_memory. but we need to move mtrr_bp_init calling into setup_arch. YH YH ^ permalink raw reply [flat|nested] 87+ messages in thread
[parent not found: <200801202255.02645.yinghai.lu@sun.com>]
[parent not found: <200801202255.58642.yinghai.lu@sun.com>]
* [PATCH] x86_32: trim memory by updating e820 v2 [not found] ` <200801202255.58642.yinghai.lu@sun.com> @ 2008-01-21 6:56 ` Yinghai Lu 2008-01-21 16:30 ` Jesse Barnes 2008-01-22 16:51 ` Ingo Molnar 0 siblings, 2 replies; 87+ messages in thread From: Yinghai Lu @ 2008-01-21 6:56 UTC (permalink / raw) To: Andi Kleen, Ingo Molnar, H. Peter Anvin; +Cc: LKML, Jesse Barnes, Andrew Morton [PATCH] x86_32: trim memory by updating e820 v2 when mtrr is not covering all e820 table, need to trim the ram, need to update e820 reuse some code for x86_64 here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early compiled test only, need someone test it Index: linux-2.6/arch/x86/kernel/cpu/common.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/common.c +++ linux-2.6/arch/x86/kernel/cpu/common.c @@ -396,11 +396,9 @@ __setup("serialnumber", x86_serial_nr_se /* * This does the hard work of actually picking apart the CPU stuff... */ -void __cpuinit identify_cpu(struct cpuinfo_x86 *c) +void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c) { - int i; - c->loops_per_jiffy = loops_per_jiffy; c->x86_cache_size = -1; c->x86_vendor = X86_VENDOR_UNKNOWN; c->cpuid_level = -1; /* CPUID not detected */ @@ -424,7 +422,14 @@ void __cpuinit identify_cpu(struct cpuin if (this_cpu->c_identify) this_cpu->c_identify(c); +} +void __cpuinit identify_cpu(struct cpuinfo_x86 *c) +{ + int i; + + c->loops_per_jiffy = loops_per_jiffy; + early_identify_cpu(c); /* * Vendor-specific initialization. In this section we * canonicalize the feature flags, meaning if there are @@ -485,7 +490,6 @@ void __init identify_boot_cpu(void) identify_cpu(&boot_cpu_data); sysenter_setup(); enable_sep_cpu(); - mtrr_bp_init(); } void __cpuinit identify_secondary_cpu(struct cpuinfo_x86 *c) Index: linux-2.6/arch/x86/kernel/setup_32.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/setup_32.c +++ linux-2.6/arch/x86/kernel/setup_32.c @@ -49,6 +49,7 @@ #include <video/edid.h> +#include <asm/mtrr.h> #include <asm/apic.h> #include <asm/e820.h> #include <asm/mpspec.h> @@ -747,6 +748,7 @@ void __init setup_arch(char **cmdline_p) bss_resource.start = virt_to_phys(&__bss_start); bss_resource.end = virt_to_phys(&__bss_stop)-1; + early_identify_cpu(&boot_cpu_data); parse_early_param(); if (user_defined_memmap) { @@ -762,6 +764,12 @@ void __init setup_arch(char **cmdline_p) max_low_pfn = setup_memory(); + /* update e820 for memory not covered by WB MTRRs */ + mtrr_bp_init(); + if (mtrr_trim_uncached_memory(max_pfn)) { + max_low_pfn = setup_memory(); + } + #ifdef CONFIG_VMI /* * Must be after max_low_pfn is determined, and before kernel Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c +++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c @@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; -#ifdef CONFIG_X86_64 static int disable_mtrr_trim; static int __init disable_mtrr_trim_setup(char *str) @@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(uns return 0; } -#endif /** * mtrr_bp_init - initialize mtrrs on the boot CPU Index: linux-2.6/Documentation/kernel-parameters.txt =================================================================== --- linux-2.6.orig/Documentation/kernel-parameters.txt +++ linux-2.6/Documentation/kernel-parameters.txt @@ -575,7 +575,7 @@ and is between 256 and 4096 characters. See drivers/char/README.epca and Documentation/digiepca.txt. - disable_mtrr_trim [X86-64, Intel only] + disable_mtrr_trim [X86, Intel and AMD only] By default the kernel will trim any uncacheable memory out of your available memory pool based on MTRR settings. This parameter disables that behavior, Index: linux-2.6/include/asm-x86/processor.h =================================================================== --- linux-2.6.orig/include/asm-x86/processor.h +++ linux-2.6/include/asm-x86/processor.h @@ -131,6 +131,7 @@ DECLARE_PER_CPU(struct cpuinfo_x86, cpu_ void cpu_detect(struct cpuinfo_x86 *c); +extern void early_identify_cpu(struct cpuinfo_x86 *); extern void identify_cpu(struct cpuinfo_x86 *); extern void identify_boot_cpu(void); extern void identify_secondary_cpu(struct cpuinfo_x86 *); Index: linux-2.6/arch/x86/kernel/e820_32.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/e820_32.c +++ linux-2.6/arch/x86/kernel/e820_32.c @@ -827,3 +827,14 @@ static int __init parse_memmap(char *arg return 0; } early_param("memmap", parse_memmap); +void __init update_e820(void) +{ + u8 nr_map; + + nr_map = e820.nr_map; + if (sanitize_e820_map(e820.map, &nr_map)) + return; + e820.nr_map = nr_map; + printk(KERN_INFO "modified physical RAM map:\n"); + print_memory_map("modified"); +} Index: linux-2.6/include/asm-x86/e820_32.h =================================================================== --- linux-2.6.orig/include/asm-x86/e820_32.h +++ linux-2.6/include/asm-x86/e820_32.h @@ -19,6 +19,7 @@ #ifndef __ASSEMBLY__ extern struct e820map e820; +extern void update_e820(void); extern int e820_all_mapped(u64 start, u64 end, unsigned type); extern int e820_any_mapped(u64 start, u64 end, unsigned type); @@ -29,6 +30,8 @@ extern int is_memory_all_valid(u64 start extern int is_memory_all_reserved(u64 start, u64 end); extern void find_max_pfn(void); extern void register_bootmem_low_pages(unsigned long max_low_pfn); +extern void add_memory_region(unsigned long long start, + unsigned long long size, int type); extern void e820_register_memory(void); extern void limit_regions(unsigned long long size); extern void print_memory_map(char *who); --- a/arch/x86/kernel/setup_64.c 2008-01-20 22:00:46.000000000 -0800 +++ b/arch/x86/kernel/setup_64.c 2008-01-20 22:01:21.000000000 -0800 @@ -158,8 +158,6 @@ .flags = IORESOURCE_RAM, }; -static void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c); - #ifdef CONFIG_PROC_VMCORE /* elfcorehdr= specifies the location of elf core header * stored by the crashed kernel. This option will be passed @@ -891,7 +889,7 @@ /* Do some early cpuid on the boot CPU to get some parameter that are needed before check_bugs. Everything advanced is in identify_cpu below. */ -static void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c) +void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c) { u32 tfms, xlvl; ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v2 2008-01-21 6:56 ` [PATCH] x86_32: trim memory by updating e820 v2 Yinghai Lu @ 2008-01-21 16:30 ` Jesse Barnes 2008-01-21 19:14 ` Justin Piszcz 2008-01-22 16:51 ` Ingo Molnar 1 sibling, 1 reply; 87+ messages in thread From: Jesse Barnes @ 2008-01-21 16:30 UTC (permalink / raw) To: Yinghai Lu Cc: Andi Kleen, Ingo Molnar, H. Peter Anvin, LKML, Andrew Morton, Justin Piszcz On Sunday, January 20, 2008 10:56 pm Yinghai Lu wrote: > [PATCH] x86_32: trim memory by updating e820 v2 > > when mtrr is not covering all e820 table, need to trim the ram, need to > update e820 > > reuse some code for x86_64 > > here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early > > compiled test only, need someone test it I like this approach too. So as long as the E820 modification method works (i.e. we have some testers, maybe Justin can give it a try), you can add Signed-off-by: Jesse Barnes <jesse.barnes@intel.com> or Acked-by: Jesse Barnes <jesse.barnes@intel.com> as appropriate too. Thanks, Jesse ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v2 2008-01-21 16:30 ` Jesse Barnes @ 2008-01-21 19:14 ` Justin Piszcz 2008-01-21 20:09 ` Yinghai Lu 0 siblings, 1 reply; 87+ messages in thread From: Justin Piszcz @ 2008-01-21 19:14 UTC (permalink / raw) To: Jesse Barnes Cc: Yinghai Lu, Andi Kleen, Ingo Molnar, H. Peter Anvin, LKML, Andrew Morton On Mon, 21 Jan 2008, Jesse Barnes wrote: > On Sunday, January 20, 2008 10:56 pm Yinghai Lu wrote: >> [PATCH] x86_32: trim memory by updating e820 v2 >> >> when mtrr is not covering all e820 table, need to trim the ram, need to >> update e820 >> >> reuse some code for x86_64 >> >> here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early >> >> compiled test only, need someone test it > > I like this approach too. So as long as the E820 modification method works > (i.e. we have some testers, maybe Justin can give it a try), you can add > > Signed-off-by: Jesse Barnes <jesse.barnes@intel.com> > > or > > Acked-by: Jesse Barnes <jesse.barnes@intel.com> > > as appropriate too. > > Thanks, > Jesse > Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2 ^^ I run x86_64 btw-- if there is a kernel.patch for x86_64 please let me know and I can test, thanks. Justin. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v2 2008-01-21 19:14 ` Justin Piszcz @ 2008-01-21 20:09 ` Yinghai Lu 2008-01-21 21:37 ` Justin Piszcz 0 siblings, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-01-21 20:09 UTC (permalink / raw) To: Justin Piszcz Cc: Jesse Barnes, Andi Kleen, Ingo Molnar, H. Peter Anvin, LKML, Andrew Morton On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote: > > On Mon, 21 Jan 2008, Jesse Barnes wrote: > > > On Sunday, January 20, 2008 10:56 pm Yinghai Lu wrote: > >> [PATCH] x86_32: trim memory by updating e820 v2 > >> > >> when mtrr is not covering all e820 table, need to trim the ram, need to > >> update e820 > >> > >> reuse some code for x86_64 > >> > >> here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early > >> > >> compiled test only, need someone test it > > > > I like this approach too. So as long as the E820 modification method works > > (i.e. we have some testers, maybe Justin can give it a try), you can add > > > > Signed-off-by: Jesse Barnes <jesse.barnes@intel.com> > > > > or > > > > Acked-by: Jesse Barnes <jesse.barnes@intel.com> > > > > as appropriate too. > > > > Thanks, > > Jesse > > > > Subject: Re: [PATCH] x86_32: trim memory by updating e820 v2 > ^^ > > I run x86_64 btw-- if there is a kernel.patch for x86_64 please let me > know and I can test, thanks. please get x86.git git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git cd linux-2.6 #--------------{ x86.git instructions }----------> # Add Linus's tree as a remote git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git # Add Ingo's tree as a remote git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git # With that setup, just run the following to get any changes you # don't have. It will also notice any new branches Ingo/Linus # add to their repo. Look in .git/config afterwards, the format # to add new remotes is easy to figure out. git remote update #------------------------- git merge x86/master git merge x86/mm and apply [PATCH] x86_64: check if Tom2 is enabled http://lkml.org/lkml/2008/1/21/20 [PATCH] x86_64: update e820 instead of updating end_pfn v3 http://lkml.org/lkml/2008/1/21/19 [PATCH] x86_32: trim memory by updating e820 v2 http://lkml.org/lkml/2008/1/21/18 YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v2 2008-01-21 20:09 ` Yinghai Lu @ 2008-01-21 21:37 ` Justin Piszcz 2008-01-23 3:50 ` Yinghai Lu 0 siblings, 1 reply; 87+ messages in thread From: Justin Piszcz @ 2008-01-21 21:37 UTC (permalink / raw) To: Yinghai Lu Cc: Jesse Barnes, Andi Kleen, Ingo Molnar, H. Peter Anvin, LKML, Andrew Morton On Mon, 21 Jan 2008, Yinghai Lu wrote: > On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote: > please get x86.git > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > cd linux-2.6 > #--------------{ x86.git instructions }----------> > # Add Linus's tree as a remote > git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > > # Add Ingo's tree as a remote > git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git > > # With that setup, just run the following to get any changes you > # don't have. It will also notice any new branches Ingo/Linus > # add to their repo. Look in .git/config afterwards, the format > # to add new remotes is easy to figure out. > git remote update > #------------------------- > git merge x86/master > git merge x86/mm > > and apply > > [PATCH] x86_64: check if Tom2 is enabled > http://lkml.org/lkml/2008/1/21/20 > [PATCH] x86_64: update e820 instead of updating end_pfn v3 > http://lkml.org/lkml/2008/1/21/19 > [PATCH] x86_32: trim memory by updating e820 v2 > http://lkml.org/lkml/2008/1/21/18 > > YH > Thanks, I am all patched up and ready to test, unfortunately one of my disks in my RAID 1 just died, I already filled out the advanced replacement form, I will test when I receive the replacement disk. p34:~# lilo Fatal: Not all RAID-1 disks are active; use '-H' to install to active disks only p34:~# lilo -H Warning: Partial RAID-1 install on active disks only; booting is not failsafe Warning: Faulty disk in RAID-1 array; boot with caution!! Fatal: Unusual RAID bios device code: 0xFF p34:~# Don't feel like mucking up my system at the moment. Justin. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v2 2008-01-21 21:37 ` Justin Piszcz @ 2008-01-23 3:50 ` Yinghai Lu 2008-01-26 0:01 ` Justin Piszcz 0 siblings, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-01-23 3:50 UTC (permalink / raw) To: Justin Piszcz Cc: Jesse Barnes, Andi Kleen, Ingo Molnar, H. Peter Anvin, LKML, Andrew Morton On Monday 21 January 2008 01:37:09 pm Justin Piszcz wrote: > > On Mon, 21 Jan 2008, Yinghai Lu wrote: > > > On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote: > > please get x86.git > > > > git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > > cd linux-2.6 > > #--------------{ x86.git instructions }----------> > > # Add Linus's tree as a remote > > git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git > > > > # Add Ingo's tree as a remote > > git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git > > > > # With that setup, just run the following to get any changes you > > # don't have. It will also notice any new branches Ingo/Linus > > # add to their repo. Look in .git/config afterwards, the format > > # to add new remotes is easy to figure out. > > git remote update > > #------------------------- > > git merge x86/master > > git merge x86/mm > > > > and apply > > > > [PATCH] x86_64: check if Tom2 is enabled > > http://lkml.org/lkml/2008/1/21/20 > > [PATCH] x86_64: update e820 instead of updating end_pfn v3 > > http://lkml.org/lkml/2008/1/21/19 > > [PATCH] x86_32: trim memory by updating e820 v2 > > http://lkml.org/lkml/2008/1/21/18 > > > > YH > > > > Thanks, I am all patched up and ready to test, unfortunately one of my disks > in my RAID 1 just died, I already filled out the advanced replacement form, > I will test when I receive the replacement disk. please get x86.git and apply [PATCH] x86_32: trim memory by updating e820 v3 http://lkml.org/lkml/2008/1/22/394 Ingo already put other two into the tree. Thanks YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v2 2008-01-23 3:50 ` Yinghai Lu @ 2008-01-26 0:01 ` Justin Piszcz 2008-01-26 0:16 ` Yinghai Lu 2008-01-28 15:09 ` Ingo Molnar 0 siblings, 2 replies; 87+ messages in thread From: Justin Piszcz @ 2008-01-26 0:01 UTC (permalink / raw) To: Yinghai Lu Cc: Jesse Barnes, Andi Kleen, Ingo Molnar, H. Peter Anvin, LKML, Andrew Morton [-- Attachment #1: Type: TEXT/PLAIN, Size: 2758 bytes --] On Tue, 22 Jan 2008, Yinghai Lu wrote: > On Monday 21 January 2008 01:37:09 pm Justin Piszcz wrote: >> >> On Mon, 21 Jan 2008, Yinghai Lu wrote: >> >>> On Monday 21 January 2008 11:14:02 am Justin Piszcz wrote: >>> please get x86.git >>> >>> git clone git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >>> cd linux-2.6 >>> #--------------{ x86.git instructions }----------> >>> # Add Linus's tree as a remote >>> git remote add linus git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git >>> >>> # Add Ingo's tree as a remote >>> git remote add x86 git://git.kernel.org/pub/scm/linux/kernel/git/x86/linux-2.6-x86.git >>> >>> # With that setup, just run the following to get any changes you >>> # don't have. It will also notice any new branches Ingo/Linus >>> # add to their repo. Look in .git/config afterwards, the format >>> # to add new remotes is easy to figure out. >>> git remote update >>> #------------------------- >>> git merge x86/master >>> git merge x86/mm >>> >>> and apply >>> >>> [PATCH] x86_64: check if Tom2 is enabled >>> http://lkml.org/lkml/2008/1/21/20 >>> [PATCH] x86_64: update e820 instead of updating end_pfn v3 >>> http://lkml.org/lkml/2008/1/21/19 >>> [PATCH] x86_32: trim memory by updating e820 v2 >>> http://lkml.org/lkml/2008/1/21/18 >>> >>> YH >>> >> >> Thanks, I am all patched up and ready to test, unfortunately one of my disks >> in my RAID 1 just died, I already filled out the advanced replacement form, >> I will test when I receive the replacement disk. > > please get x86.git and apply > [PATCH] x86_32: trim memory by updating e820 v3 > http://lkml.org/lkml/2008/1/22/394 > > Ingo already put other two into the tree. > > Thanks > > YH > Tried it, it worked successfully! With stock kernel, previous way I had to use it was mem=8832M and top showed this: top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10 Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers Swap: 16787768k total, 0k used, 16787768k free, 178528k cached With kernel you mentioned and use e820 v3: top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25 Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers Swap: 16787768k total, 0k used, 16787768k free, 273928k cached No append mem= required. A full dmesg is attached so you can analyze the e820/MTRR mapping. File: dmesg-e820v3patch.txt.bz2 Justin. [-- Attachment #2: Type: APPLICATION/octet-stream, Size: 12040 bytes --] ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v2 2008-01-26 0:01 ` Justin Piszcz @ 2008-01-26 0:16 ` Yinghai Lu 2008-01-26 0:37 ` Justin Piszcz 2008-01-28 15:09 ` Ingo Molnar 1 sibling, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-01-26 0:16 UTC (permalink / raw) To: Justin Piszcz Cc: Jesse Barnes, Andi Kleen, Ingo Molnar, H. Peter Anvin, LKML, Andrew Morton On Jan 25, 2008 4:01 PM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote: > > ... > Tried it, it worked successfully! > > With stock kernel, previous way I had to use it was mem=8832M and top > showed this: > > top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10 > Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie > Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st > Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers > Swap: 16787768k total, 0k used, 16787768k free, 178528k cached > > With kernel you mentioned and use e820 v3: > > top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25 > Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie > Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st > Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers > Swap: 16787768k total, 0k used, 16787768k free, 273928k cached > > No append mem= required. > thanks any chance to try 32 bit with higemem64 option? YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v2 2008-01-26 0:16 ` Yinghai Lu @ 2008-01-26 0:37 ` Justin Piszcz 0 siblings, 0 replies; 87+ messages in thread From: Justin Piszcz @ 2008-01-26 0:37 UTC (permalink / raw) To: Yinghai Lu Cc: Jesse Barnes, Andi Kleen, Ingo Molnar, H. Peter Anvin, LKML, Andrew Morton On Fri, 25 Jan 2008, Yinghai Lu wrote: > On Jan 25, 2008 4:01 PM, Justin Piszcz <jpiszcz@lucidpixels.com> wrote: >> >> > ... >> Tried it, it worked successfully! >> >> With stock kernel, previous way I had to use it was mem=8832M and top >> showed this: >> >> top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10 >> Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie >> Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st >> Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers >> Swap: 16787768k total, 0k used, 16787768k free, 178528k cached >> >> With kernel you mentioned and use e820 v3: >> >> top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25 >> Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie >> Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st >> Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers >> Swap: 16787768k total, 0k used, 16787768k free, 273928k cached >> >> No append mem= required. >> > > > thanks > > any chance to try 32 bit with higemem64 option? > > YH > My distribution is setup for 64-bit (64bit-clean) only, I do not have a 32-bit userland, so cannot help here, sorry. Justin. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v2 2008-01-26 0:01 ` Justin Piszcz 2008-01-26 0:16 ` Yinghai Lu @ 2008-01-28 15:09 ` Ingo Molnar 2008-01-28 18:07 ` Justin Piszcz 1 sibling, 1 reply; 87+ messages in thread From: Ingo Molnar @ 2008-01-28 15:09 UTC (permalink / raw) To: Justin Piszcz Cc: Yinghai Lu, Jesse Barnes, Andi Kleen, H. Peter Anvin, LKML, Andrew Morton * Justin Piszcz <jpiszcz@lucidpixels.com> wrote: > Tried it, it worked successfully! > > With stock kernel, previous way I had to use it was mem=8832M and top > showed this: > > top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10 > Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie > Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st > Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers > Swap: 16787768k total, 0k used, 16787768k free, 178528k cached > > With kernel you mentioned and use e820 v3: > > top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25 > Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie > Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st > Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers > Swap: 16787768k total, 0k used, 16787768k free, 273928k cached > > No append mem= required. > > A full dmesg is attached so you can analyze the e820/MTRR mapping. thanks for testing it! The code indeed successfully trimmed your memory map by 64MB: from: [ 0.000000] BIOS-e820: 0000000100000000 - 000000022c000000 (usable) to: [ 0.000000] modified: 0000000100000000 - 0000000228000000 (usable) [ 0.000000] modified: 0000000228000000 - 000000022c000000 (reserved) what happened on your box previously when you booted without any trimming - did it sometimes slow down or something like that? Ingo ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v2 2008-01-28 15:09 ` Ingo Molnar @ 2008-01-28 18:07 ` Justin Piszcz 0 siblings, 0 replies; 87+ messages in thread From: Justin Piszcz @ 2008-01-28 18:07 UTC (permalink / raw) To: Ingo Molnar Cc: Yinghai Lu, Jesse Barnes, Andi Kleen, H. Peter Anvin, LKML, Andrew Morton On Mon, 28 Jan 2008, Ingo Molnar wrote: > > * Justin Piszcz <jpiszcz@lucidpixels.com> wrote: > >> Tried it, it worked successfully! >> >> With stock kernel, previous way I had to use it was mem=8832M and top >> showed this: >> >> top - 18:53:52 up 1 min, 2 users, load average: 1.03, 0.30, 0.10 >> Tasks: 169 total, 1 running, 168 sleeping, 0 stopped, 0 zombie >> Cpu(s): 6.1%us, 2.6%sy, 4.5%ni, 81.3%id, 5.5%wa, 0.0%hi, 0.0%si, 0.0%st >> Mem: 8039464k total, 1288948k used, 6750516k free, 3640k buffers >> Swap: 16787768k total, 0k used, 16787768k free, 178528k cached >> >> With kernel you mentioned and use e820 v3: >> >> top - 18:48:13 up 3 min, 6 users, load average: 1.67, 0.68, 0.25 >> Tasks: 195 total, 2 running, 193 sleeping, 0 stopped, 0 zombie >> Cpu(s): 18.5%us, 1.2%sy, 1.6%ni, 74.8%id, 3.9%wa, 0.0%hi, 0.0%si, 0.0%st >> Mem: 8037668k total, 1438732k used, 6598936k free, 6844k buffers >> Swap: 16787768k total, 0k used, 16787768k free, 273928k cached >> >> No append mem= required. >> >> A full dmesg is attached so you can analyze the e820/MTRR mapping. > > thanks for testing it! The code indeed successfully trimmed your memory > map by 64MB: > > from: > > [ 0.000000] BIOS-e820: 0000000100000000 - 000000022c000000 (usable) > > to: > > [ 0.000000] modified: 0000000100000000 - 0000000228000000 (usable) > [ 0.000000] modified: 0000000228000000 - 000000022c000000 (reserved) > > what happened on your box previously when you booted without any > trimming - did it sometimes slow down or something like that? > > Ingo > When I boot the box without any trimming it acts like a 286 or 386, takes about 10 minutes to boot (using raptor disks). Justin. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v2 2008-01-21 6:56 ` [PATCH] x86_32: trim memory by updating e820 v2 Yinghai Lu 2008-01-21 16:30 ` Jesse Barnes @ 2008-01-22 16:51 ` Ingo Molnar 2008-01-23 0:23 ` [PATCH] x86_32: trim memory by updating e820 v3 Yinghai Lu 1 sibling, 1 reply; 87+ messages in thread From: Ingo Molnar @ 2008-01-22 16:51 UTC (permalink / raw) To: Yinghai Lu; +Cc: Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, Andrew Morton [-- Attachment #1: Type: text/plain, Size: 7763 bytes --] * Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: > [PATCH] x86_32: trim memory by updating e820 v2 > > when mtrr is not covering all e820 table, need to trim the ram, need > to update e820 > > reuse some code for x86_64 > > here need to add early_identify_cpu for x86_32, and move mtrr_bp_init > early > > compiled test only, need someone test it i picked up the patch below, and it crashes with: Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) ------------[ cut here ]------------ kernel BUG at arch/x86/mm/pageattr_32.c:327! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC Pid: 0, comm: swapper Not tainted (2.6.24-rc8 #15) EIP: 0060:[<c0116a3f>] EFLAGS: 00010297 CPU: 0 EIP is at kernel_map_pages+0x52/0xb3 config and bootlog attached as well. Ingo ------------------> Subject: x86_32: trim memory by updating e820 From: Yinghai Lu <Yinghai.Lu@Sun.COM> when mtrr is not covering all e820 table, need to trim the ram, need to update e820 reuse some code for x86_64 here need to add early_identify_cpu for x86_32, and move mtrr_bp_init early compiled test only, need someone test it Signed-off-by: Ingo Molnar <mingo@elte.hu> --- Documentation/kernel-parameters.txt | 2 +- arch/x86/kernel/cpu/common.c | 12 ++++++++---- arch/x86/kernel/cpu/mtrr/main.c | 2 -- arch/x86/kernel/e820_32.c | 11 +++++++++++ arch/x86/kernel/setup_32.c | 7 +++++++ arch/x86/kernel/setup_64.c | 4 +--- include/asm-x86/e820_32.h | 3 +++ include/asm-x86/processor.h | 1 + 8 files changed, 32 insertions(+), 10 deletions(-) Index: linux-x86.q/Documentation/kernel-parameters.txt =================================================================== --- linux-x86.q.orig/Documentation/kernel-parameters.txt +++ linux-x86.q/Documentation/kernel-parameters.txt @@ -575,7 +575,7 @@ and is between 256 and 4096 characters. See drivers/char/README.epca and Documentation/digiepca.txt. - disable_mtrr_trim [X86-64, Intel only] + disable_mtrr_trim [X86, Intel and AMD only] By default the kernel will trim any uncacheable memory out of your available memory pool based on MTRR settings. This parameter disables that behavior, Index: linux-x86.q/arch/x86/kernel/cpu/common.c =================================================================== --- linux-x86.q.orig/arch/x86/kernel/cpu/common.c +++ linux-x86.q/arch/x86/kernel/cpu/common.c @@ -396,11 +396,9 @@ __setup("serialnumber", x86_serial_nr_se /* * This does the hard work of actually picking apart the CPU stuff... */ -void __cpuinit identify_cpu(struct cpuinfo_x86 *c) +void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c) { - int i; - c->loops_per_jiffy = loops_per_jiffy; c->x86_cache_size = -1; c->x86_vendor = X86_VENDOR_UNKNOWN; c->cpuid_level = -1; /* CPUID not detected */ @@ -424,7 +422,14 @@ void __cpuinit identify_cpu(struct cpuin if (this_cpu->c_identify) this_cpu->c_identify(c); +} +void __cpuinit identify_cpu(struct cpuinfo_x86 *c) +{ + int i; + + c->loops_per_jiffy = loops_per_jiffy; + early_identify_cpu(c); /* * Vendor-specific initialization. In this section we * canonicalize the feature flags, meaning if there are @@ -485,7 +490,6 @@ void __init identify_boot_cpu(void) identify_cpu(&boot_cpu_data); sysenter_setup(); enable_sep_cpu(); - mtrr_bp_init(); } void __cpuinit identify_secondary_cpu(struct cpuinfo_x86 *c) Index: linux-x86.q/arch/x86/kernel/cpu/mtrr/main.c =================================================================== --- linux-x86.q.orig/arch/x86/kernel/cpu/mtrr/main.c +++ linux-x86.q/arch/x86/kernel/cpu/mtrr/main.c @@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; -#ifdef CONFIG_X86_64 static int disable_mtrr_trim; static int __init disable_mtrr_trim_setup(char *str) @@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(uns return 0; } -#endif /** * mtrr_bp_init - initialize mtrrs on the boot CPU Index: linux-x86.q/arch/x86/kernel/e820_32.c =================================================================== --- linux-x86.q.orig/arch/x86/kernel/e820_32.c +++ linux-x86.q/arch/x86/kernel/e820_32.c @@ -749,3 +749,14 @@ static int __init parse_memmap(char *arg return 0; } early_param("memmap", parse_memmap); +void __init update_e820(void) +{ + u8 nr_map; + + nr_map = e820.nr_map; + if (sanitize_e820_map(e820.map, &nr_map)) + return; + e820.nr_map = nr_map; + printk(KERN_INFO "modified physical RAM map:\n"); + print_memory_map("modified"); +} Index: linux-x86.q/arch/x86/kernel/setup_32.c =================================================================== --- linux-x86.q.orig/arch/x86/kernel/setup_32.c +++ linux-x86.q/arch/x86/kernel/setup_32.c @@ -49,6 +49,7 @@ #include <video/edid.h> +#include <asm/mtrr.h> #include <asm/apic.h> #include <asm/e820.h> #include <asm/mpspec.h> @@ -747,6 +748,7 @@ void __init setup_arch(char **cmdline_p) bss_resource.start = virt_to_phys(&__bss_start); bss_resource.end = virt_to_phys(&__bss_stop)-1; + early_identify_cpu(&boot_cpu_data); parse_early_param(); if (user_defined_memmap) { @@ -762,6 +764,11 @@ void __init setup_arch(char **cmdline_p) max_low_pfn = setup_memory(); + /* update e820 for memory not covered by WB MTRRs */ + mtrr_bp_init(); + if (mtrr_trim_uncached_memory(max_pfn)) + max_low_pfn = setup_memory(); + #ifdef CONFIG_VMI /* * Must be after max_low_pfn is determined, and before kernel Index: linux-x86.q/arch/x86/kernel/setup_64.c =================================================================== --- linux-x86.q.orig/arch/x86/kernel/setup_64.c +++ linux-x86.q/arch/x86/kernel/setup_64.c @@ -157,8 +157,6 @@ static struct resource bss_resource = { .flags = IORESOURCE_RAM, }; -static void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c); - #ifdef CONFIG_PROC_VMCORE /* elfcorehdr= specifies the location of elf core header * stored by the crashed kernel. This option will be passed @@ -890,7 +888,7 @@ struct cpu_model_info { /* Do some early cpuid on the boot CPU to get some parameter that are needed before check_bugs. Everything advanced is in identify_cpu below. */ -static void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c) +void __cpuinit early_identify_cpu(struct cpuinfo_x86 *c) { u32 tfms, xlvl; Index: linux-x86.q/include/asm-x86/e820_32.h =================================================================== --- linux-x86.q.orig/include/asm-x86/e820_32.h +++ linux-x86.q/include/asm-x86/e820_32.h @@ -19,12 +19,15 @@ #ifndef __ASSEMBLY__ extern struct e820map e820; +extern void update_e820(void); extern int e820_all_mapped(unsigned long start, unsigned long end, unsigned type); extern int e820_any_mapped(u64 start, u64 end, unsigned type); extern void find_max_pfn(void); extern void register_bootmem_low_pages(unsigned long max_low_pfn); +extern void add_memory_region(unsigned long long start, + unsigned long long size, int type); extern void e820_register_memory(void); extern void limit_regions(unsigned long long size); extern void print_memory_map(char *who); Index: linux-x86.q/include/asm-x86/processor.h =================================================================== --- linux-x86.q.orig/include/asm-x86/processor.h +++ linux-x86.q/include/asm-x86/processor.h @@ -131,6 +131,7 @@ DECLARE_PER_CPU(struct cpuinfo_x86, cpu_ void cpu_detect(struct cpuinfo_x86 *c); +extern void early_identify_cpu(struct cpuinfo_x86 *); extern void identify_cpu(struct cpuinfo_x86 *); extern void identify_boot_cpu(void); extern void identify_secondary_cpu(struct cpuinfo_x86 *); [-- Attachment #2: config --] [-- Type: text/plain, Size: 44668 bytes --] # # Automatically generated make config: don't edit # Linux kernel version: 2.6.24-rc8 # Tue Jan 22 17:33:45 2008 # # CONFIG_64BIT is not set CONFIG_X86_32=y # CONFIG_X86_64 is not set CONFIG_X86=y # CONFIG_GENERIC_LOCKBREAK is not set CONFIG_GENERIC_TIME=y CONFIG_GENERIC_CMOS_UPDATE=y CONFIG_CLOCKSOURCE_WATCHDOG=y CONFIG_GENERIC_CLOCKEVENTS=y CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y CONFIG_LOCKDEP_SUPPORT=y CONFIG_STACKTRACE_SUPPORT=y CONFIG_SEMAPHORE_SLEEPERS=y CONFIG_MMU=y CONFIG_ZONE_DMA=y CONFIG_QUICKLIST=y CONFIG_GENERIC_ISA_DMA=y CONFIG_GENERIC_IOMAP=y CONFIG_GENERIC_BUG=y # CONFIG_GENERIC_GPIO is not set CONFIG_GENERIC_HWEIGHT=y CONFIG_ARCH_MAY_HAVE_PC_FDC=y CONFIG_DMI=y CONFIG_RWSEM_GENERIC_SPINLOCK=y # CONFIG_RWSEM_XCHGADD_ALGORITHM is not set # CONFIG_ARCH_HAS_ILOG2_U32 is not set # CONFIG_ARCH_HAS_ILOG2_U64 is not set CONFIG_GENERIC_CALIBRATE_DELAY=y # CONFIG_GENERIC_TIME_VSYSCALL is not set # CONFIG_ARCH_SETS_UP_PER_CPU_AREA is not set CONFIG_ARCH_SUPPORTS_OPROFILE=y # CONFIG_ZONE_DMA32 is not set CONFIG_ARCH_POPULATES_NODE_MAP=y # CONFIG_AUDIT_ARCH is not set CONFIG_GENERIC_HARDIRQS=y CONFIG_GENERIC_IRQ_PROBE=y CONFIG_GENERIC_PENDING_IRQ=y CONFIG_X86_SMP=y CONFIG_X86_32_SMP=y CONFIG_X86_HT=y CONFIG_X86_BIOS_REBOOT=y CONFIG_X86_TRAMPOLINE=y CONFIG_KTIME_SCALAR=y CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config" # # General setup # CONFIG_EXPERIMENTAL=y CONFIG_LOCK_KERNEL=y CONFIG_INIT_ENV_ARG_LIMIT=32 CONFIG_LOCALVERSION="" CONFIG_LOCALVERSION_AUTO=y CONFIG_SWAP=y # CONFIG_SYSVIPC is not set # CONFIG_POSIX_MQUEUE is not set # CONFIG_BSD_PROCESS_ACCT is not set # CONFIG_TASKSTATS is not set CONFIG_USER_NS=y CONFIG_PID_NS=y # CONFIG_AUDIT is not set CONFIG_IKCONFIG=y # CONFIG_IKCONFIG_PROC is not set CONFIG_LOG_BUF_SHIFT=20 CONFIG_CGROUPS=y # CONFIG_CGROUP_DEBUG is not set CONFIG_CGROUP_NS=y # CONFIG_CPUSETS is not set CONFIG_FAIR_GROUP_SCHED=y CONFIG_FAIR_USER_SCHED=y # CONFIG_FAIR_CGROUP_SCHED is not set CONFIG_CGROUP_CPUACCT=y CONFIG_SYSFS_DEPRECATED=y CONFIG_RELAY=y CONFIG_BLK_DEV_INITRD=y CONFIG_INITRAMFS_SOURCE="" CONFIG_CC_OPTIMIZE_FOR_SIZE=y CONFIG_SYSCTL=y # CONFIG_EMBEDDED is not set CONFIG_UID16=y CONFIG_SYSCTL_SYSCALL=y CONFIG_KALLSYMS=y CONFIG_KALLSYMS_ALL=y CONFIG_KALLSYMS_EXTRA_PASS=y CONFIG_HOTPLUG=y CONFIG_PRINTK=y CONFIG_BUG=y CONFIG_ELF_CORE=y CONFIG_BASE_FULL=y CONFIG_FUTEX=y CONFIG_ANON_INODES=y CONFIG_EPOLL=y CONFIG_SIGNALFD=y CONFIG_EVENTFD=y CONFIG_SHMEM=y CONFIG_VM_EVENT_COUNTERS=y CONFIG_SLUB_DEBUG=y # CONFIG_SLAB is not set CONFIG_SLUB=y # CONFIG_SLOB is not set CONFIG_SLABINFO=y CONFIG_RT_MUTEXES=y # CONFIG_TINY_SHMEM is not set CONFIG_BASE_SMALL=0 # CONFIG_MODULES is not set CONFIG_STOP_MACHINE=y CONFIG_BLOCK=y # CONFIG_LBD is not set CONFIG_BLK_DEV_IO_TRACE=y # CONFIG_LSF is not set # CONFIG_BLK_DEV_BSG is not set # # IO Schedulers # CONFIG_IOSCHED_NOOP=y # CONFIG_IOSCHED_AS is not set # CONFIG_IOSCHED_DEADLINE is not set CONFIG_IOSCHED_CFQ=y # CONFIG_DEFAULT_AS is not set # CONFIG_DEFAULT_DEADLINE is not set CONFIG_DEFAULT_CFQ=y # CONFIG_DEFAULT_NOOP is not set CONFIG_DEFAULT_IOSCHED="cfq" # # Processor type and features # # CONFIG_TICK_ONESHOT is not set # CONFIG_NO_HZ is not set # CONFIG_HIGH_RES_TIMERS is not set CONFIG_GENERIC_CLOCKEVENTS_BUILD=y CONFIG_SMP=y CONFIG_X86_PC=y # CONFIG_X86_ELAN is not set # CONFIG_X86_VOYAGER is not set # CONFIG_X86_NUMAQ is not set # CONFIG_X86_SUMMIT is not set # CONFIG_X86_BIGSMP is not set # CONFIG_X86_VISWS is not set # CONFIG_X86_GENERICARCH is not set # CONFIG_X86_ES7000 is not set # CONFIG_X86_RDC321X is not set # CONFIG_X86_VSMP is not set # CONFIG_SCHED_NO_NO_OMIT_FRAME_POINTER is not set # CONFIG_PARAVIRT_GUEST is not set CONFIG_M386=y # CONFIG_M486 is not set # CONFIG_M586 is not set # CONFIG_M586TSC is not set # CONFIG_M586MMX is not set # CONFIG_M686 is not set # CONFIG_MPENTIUMII is not set # CONFIG_MPENTIUMIII is not set # CONFIG_MPENTIUMM is not set # CONFIG_MPENTIUM4 is not set # CONFIG_MK6 is not set # CONFIG_MK7 is not set # CONFIG_MK8 is not set # CONFIG_MCRUSOE is not set # CONFIG_MEFFICEON is not set # CONFIG_MWINCHIPC6 is not set # CONFIG_MWINCHIP2 is not set # CONFIG_MWINCHIP3D is not set # CONFIG_MGEODEGX1 is not set # CONFIG_MGEODE_LX is not set # CONFIG_MCYRIXIII is not set # CONFIG_MVIAC3_2 is not set # CONFIG_MVIAC7 is not set # CONFIG_MPSC is not set # CONFIG_MCORE2 is not set # CONFIG_GENERIC_CPU is not set # CONFIG_X86_GENERIC is not set # CONFIG_X86_CMPXCHG is not set CONFIG_X86_L1_CACHE_SHIFT=4 CONFIG_X86_PPRO_FENCE=y CONFIG_X86_F00F_BUG=y CONFIG_X86_MINIMUM_CPU_FAMILY=3 # CONFIG_HPET_TIMER is not set CONFIG_NR_CPUS=8 CONFIG_SCHED_SMT=y # CONFIG_SCHED_MC is not set CONFIG_PREEMPT_NONE=y # CONFIG_PREEMPT_VOLUNTARY is not set # CONFIG_PREEMPT is not set CONFIG_PREEMPT_BKL=y CONFIG_X86_LOCAL_APIC=y CONFIG_X86_IO_APIC=y # CONFIG_X86_MCE is not set CONFIG_VM86=y CONFIG_TOSHIBA=y CONFIG_I8K=y CONFIG_X86_REBOOTFIXUPS=y CONFIG_MICROCODE=y CONFIG_MICROCODE_OLD_INTERFACE=y CONFIG_X86_MSR=y CONFIG_X86_CPUID=y CONFIG_NOHIGHMEM=y # CONFIG_HIGHMEM4G is not set # CONFIG_HIGHMEM64G is not set CONFIG_PAGE_OFFSET=0xC0000000 # CONFIG_X86_PAE is not set CONFIG_ARCH_FLATMEM_ENABLE=y CONFIG_ARCH_SPARSEMEM_ENABLE=y CONFIG_ARCH_SELECT_MEMORY_MODEL=y CONFIG_SELECT_MEMORY_MODEL=y CONFIG_FLATMEM_MANUAL=y # CONFIG_DISCONTIGMEM_MANUAL is not set # CONFIG_SPARSEMEM_MANUAL is not set CONFIG_FLATMEM=y CONFIG_FLAT_NODE_MEM_MAP=y CONFIG_SPARSEMEM_STATIC=y # CONFIG_SPARSEMEM_VMEMMAP_ENABLE is not set CONFIG_SPLIT_PTLOCK_CPUS=4 # CONFIG_RESOURCES_64BIT is not set CONFIG_ZONE_DMA_FLAG=1 CONFIG_BOUNCE=y CONFIG_NR_QUICK=1 CONFIG_VIRT_TO_BUS=y # CONFIG_MATH_EMULATION is not set CONFIG_MTRR=y # CONFIG_EFI is not set CONFIG_IRQBALANCE=y # CONFIG_SECCOMP is not set # CONFIG_HZ_100 is not set # CONFIG_HZ_250 is not set CONFIG_HZ_300=y # CONFIG_HZ_1000 is not set CONFIG_HZ=300 # CONFIG_KEXEC is not set CONFIG_PHYSICAL_START=0x100000 # CONFIG_RELOCATABLE is not set CONFIG_PHYSICAL_ALIGN=0x100000 CONFIG_HOTPLUG_CPU=y CONFIG_COMPAT_VDSO=y # # Power management options # CONFIG_PM=y # CONFIG_PM_LEGACY is not set # CONFIG_PM_DEBUG is not set CONFIG_SUSPEND_SMP_POSSIBLE=y # CONFIG_SUSPEND is not set CONFIG_HIBERNATION_SMP_POSSIBLE=y # CONFIG_HIBERNATION is not set CONFIG_ACPI=y CONFIG_ACPI_PROCFS=y # CONFIG_ACPI_PROCFS_POWER is not set CONFIG_ACPI_SYSFS_POWER=y CONFIG_ACPI_PROC_EVENT=y CONFIG_ACPI_AC=y CONFIG_ACPI_BATTERY=y # CONFIG_ACPI_BUTTON is not set CONFIG_ACPI_FAN=y # CONFIG_ACPI_DOCK is not set # CONFIG_ACPI_PROCESSOR is not set # CONFIG_ACPI_ASUS is not set # CONFIG_ACPI_TOSHIBA is not set CONFIG_ACPI_BLACKLIST_YEAR=0 CONFIG_ACPI_DEBUG=y CONFIG_ACPI_DEBUG_FUNC_TRACE=y CONFIG_ACPI_EC=y CONFIG_ACPI_POWER=y CONFIG_ACPI_SYSTEM=y CONFIG_X86_PM_TIMER=y # CONFIG_ACPI_CONTAINER is not set CONFIG_ACPI_SBS=y # # CPU Frequency scaling # # CONFIG_CPU_FREQ is not set CONFIG_CPU_IDLE=y CONFIG_CPU_IDLE_GOV_LADDER=y # # Bus options (PCI etc.) # CONFIG_PCI=y # CONFIG_PCI_GOBIOS is not set # CONFIG_PCI_GOMMCONFIG is not set # CONFIG_PCI_GODIRECT is not set CONFIG_PCI_GOANY=y CONFIG_PCI_BIOS=y CONFIG_PCI_DIRECT=y CONFIG_PCI_MMCONFIG=y CONFIG_PCI_DOMAINS=y # CONFIG_PCIEPORTBUS is not set CONFIG_ARCH_SUPPORTS_MSI=y CONFIG_PCI_MSI=y CONFIG_PCI_LEGACY=y # CONFIG_PCI_DEBUG is not set CONFIG_HT_IRQ=y CONFIG_ISA_DMA_API=y # CONFIG_ISA is not set CONFIG_MCA=y CONFIG_MCA_LEGACY=y # CONFIG_MCA_PROC_FS is not set CONFIG_SCx200=y # CONFIG_SCx200HR_TIMER is not set CONFIG_PCCARD=y # CONFIG_PCMCIA_DEBUG is not set # CONFIG_PCMCIA is not set CONFIG_CARDBUS=y # # PC-card bridges # # CONFIG_YENTA is not set CONFIG_HOTPLUG_PCI=y # CONFIG_HOTPLUG_PCI_FAKE is not set CONFIG_HOTPLUG_PCI_COMPAQ=y CONFIG_HOTPLUG_PCI_COMPAQ_NVRAM=y # CONFIG_HOTPLUG_PCI_IBM is not set CONFIG_HOTPLUG_PCI_ACPI=y CONFIG_HOTPLUG_PCI_ACPI_IBM=y # CONFIG_HOTPLUG_PCI_CPCI is not set CONFIG_HOTPLUG_PCI_SHPC=y # # Executable file formats / Emulations # CONFIG_BINFMT_ELF=y CONFIG_BINFMT_AOUT=y # CONFIG_BINFMT_MISC is not set # # Networking # CONFIG_NET=y # # Networking options # CONFIG_PACKET=y CONFIG_PACKET_MMAP=y CONFIG_UNIX=y CONFIG_XFRM=y CONFIG_XFRM_USER=y # CONFIG_XFRM_SUB_POLICY is not set # CONFIG_XFRM_MIGRATE is not set # CONFIG_NET_KEY is not set CONFIG_INET=y CONFIG_IP_MULTICAST=y # CONFIG_IP_ADVANCED_ROUTER is not set CONFIG_IP_FIB_HASH=y CONFIG_IP_PNP=y CONFIG_IP_PNP_DHCP=y CONFIG_IP_PNP_BOOTP=y CONFIG_IP_PNP_RARP=y # CONFIG_NET_IPIP is not set CONFIG_NET_IPGRE=y # CONFIG_NET_IPGRE_BROADCAST is not set # CONFIG_IP_MROUTE is not set CONFIG_ARPD=y CONFIG_SYN_COOKIES=y # CONFIG_INET_AH is not set # CONFIG_INET_ESP is not set # CONFIG_INET_IPCOMP is not set # CONFIG_INET_XFRM_TUNNEL is not set # CONFIG_INET_TUNNEL is not set CONFIG_INET_XFRM_MODE_TRANSPORT=y CONFIG_INET_XFRM_MODE_TUNNEL=y CONFIG_INET_XFRM_MODE_BEET=y CONFIG_INET_LRO=y CONFIG_INET_DIAG=y CONFIG_INET_TCP_DIAG=y # CONFIG_TCP_CONG_ADVANCED is not set CONFIG_TCP_CONG_CUBIC=y CONFIG_DEFAULT_TCP_CONG="cubic" CONFIG_TCP_MD5SIG=y # CONFIG_IP_VS is not set CONFIG_IPV6=y # CONFIG_IPV6_PRIVACY is not set CONFIG_IPV6_ROUTER_PREF=y CONFIG_IPV6_ROUTE_INFO=y # CONFIG_IPV6_OPTIMISTIC_DAD is not set # CONFIG_INET6_AH is not set CONFIG_INET6_ESP=y CONFIG_INET6_IPCOMP=y CONFIG_IPV6_MIP6=y CONFIG_INET6_XFRM_TUNNEL=y CONFIG_INET6_TUNNEL=y CONFIG_INET6_XFRM_MODE_TRANSPORT=y CONFIG_INET6_XFRM_MODE_TUNNEL=y # CONFIG_INET6_XFRM_MODE_BEET is not set CONFIG_INET6_XFRM_MODE_ROUTEOPTIMIZATION=y # CONFIG_IPV6_SIT is not set CONFIG_IPV6_TUNNEL=y CONFIG_IPV6_MULTIPLE_TABLES=y CONFIG_IPV6_SUBTREES=y CONFIG_NETLABEL=y # CONFIG_NETWORK_SECMARK is not set CONFIG_NETFILTER=y CONFIG_NETFILTER_DEBUG=y # # Core Netfilter Configuration # # CONFIG_NETFILTER_NETLINK is not set # CONFIG_NF_CONNTRACK_ENABLED is not set # CONFIG_NF_CONNTRACK is not set CONFIG_NETFILTER_XTABLES=y CONFIG_NETFILTER_XT_TARGET_CLASSIFY=y CONFIG_NETFILTER_XT_TARGET_MARK=y # CONFIG_NETFILTER_XT_TARGET_NFQUEUE is not set CONFIG_NETFILTER_XT_TARGET_NFLOG=y CONFIG_NETFILTER_XT_TARGET_TCPMSS=y CONFIG_NETFILTER_XT_MATCH_COMMENT=y # CONFIG_NETFILTER_XT_MATCH_DCCP is not set # CONFIG_NETFILTER_XT_MATCH_DSCP is not set CONFIG_NETFILTER_XT_MATCH_ESP=y CONFIG_NETFILTER_XT_MATCH_LENGTH=y # CONFIG_NETFILTER_XT_MATCH_LIMIT is not set # CONFIG_NETFILTER_XT_MATCH_MAC is not set CONFIG_NETFILTER_XT_MATCH_MARK=y # CONFIG_NETFILTER_XT_MATCH_POLICY is not set CONFIG_NETFILTER_XT_MATCH_MULTIPORT=y # CONFIG_NETFILTER_XT_MATCH_PKTTYPE is not set CONFIG_NETFILTER_XT_MATCH_QUOTA=y # CONFIG_NETFILTER_XT_MATCH_REALM is not set # CONFIG_NETFILTER_XT_MATCH_SCTP is not set # CONFIG_NETFILTER_XT_MATCH_STATISTIC is not set CONFIG_NETFILTER_XT_MATCH_STRING=y # CONFIG_NETFILTER_XT_MATCH_TCPMSS is not set # CONFIG_NETFILTER_XT_MATCH_TIME is not set # CONFIG_NETFILTER_XT_MATCH_U32 is not set # CONFIG_NETFILTER_XT_MATCH_HASHLIMIT is not set # # IP: Netfilter Configuration # # CONFIG_IP_NF_QUEUE is not set # CONFIG_IP_NF_IPTABLES is not set CONFIG_IP_NF_ARPTABLES=y # CONFIG_IP_NF_ARPFILTER is not set CONFIG_IP_NF_ARP_MANGLE=y # # IPv6: Netfilter Configuration (EXPERIMENTAL) # # CONFIG_IP6_NF_QUEUE is not set # CONFIG_IP6_NF_IPTABLES is not set # # DECnet: Netfilter Configuration # # CONFIG_DECNET_NF_GRABULATOR is not set # CONFIG_IP_DCCP is not set CONFIG_IP_SCTP=y # CONFIG_SCTP_DBG_MSG is not set # CONFIG_SCTP_DBG_OBJCNT is not set # CONFIG_SCTP_HMAC_NONE is not set CONFIG_SCTP_HMAC_SHA1=y # CONFIG_SCTP_HMAC_MD5 is not set CONFIG_TIPC=y # CONFIG_TIPC_ADVANCED is not set # CONFIG_TIPC_DEBUG is not set # CONFIG_ATM is not set # CONFIG_BRIDGE is not set # CONFIG_VLAN_8021Q is not set CONFIG_DECNET=y # CONFIG_DECNET_ROUTER is not set CONFIG_LLC=y CONFIG_LLC2=y # CONFIG_IPX is not set CONFIG_ATALK=y CONFIG_DEV_APPLETALK=y CONFIG_IPDDP=y # CONFIG_IPDDP_ENCAP is not set CONFIG_IPDDP_DECAP=y # CONFIG_X25 is not set CONFIG_LAPB=y CONFIG_ECONET=y # CONFIG_ECONET_AUNUDP is not set # CONFIG_ECONET_NATIVE is not set # CONFIG_WAN_ROUTER is not set # CONFIG_NET_SCHED is not set # # Network testing # CONFIG_NET_PKTGEN=y # CONFIG_HAMRADIO is not set CONFIG_IRDA=y # # IrDA protocols # # CONFIG_IRLAN is not set # CONFIG_IRCOMM is not set # CONFIG_IRDA_ULTRA is not set # # IrDA options # CONFIG_IRDA_CACHE_LAST_LSAP=y # CONFIG_IRDA_FAST_RR is not set # CONFIG_IRDA_DEBUG is not set # # Infrared-port device drivers # # # SIR device drivers # CONFIG_IRTTY_SIR=y # # Dongle support # CONFIG_DONGLE=y # CONFIG_ESI_DONGLE is not set # CONFIG_ACTISYS_DONGLE is not set # CONFIG_TEKRAM_DONGLE is not set # CONFIG_TOIM3232_DONGLE is not set # CONFIG_LITELINK_DONGLE is not set CONFIG_MA600_DONGLE=y CONFIG_GIRBIL_DONGLE=y # CONFIG_MCP2120_DONGLE is not set # CONFIG_OLD_BELKIN_DONGLE is not set # CONFIG_ACT200L_DONGLE is not set CONFIG_KINGSUN_DONGLE=y # CONFIG_KSDAZZLE_DONGLE is not set CONFIG_KS959_DONGLE=y # # Old SIR device drivers # # # Old Serial dongle support # # # FIR device drivers # CONFIG_USB_IRDA=y CONFIG_SIGMATEL_FIR=y # CONFIG_NSC_FIR is not set CONFIG_WINBOND_FIR=y CONFIG_TOSHIBA_FIR=y # CONFIG_SMC_IRCC_FIR is not set # CONFIG_ALI_FIR is not set CONFIG_VLSI_FIR=y # CONFIG_VIA_FIR is not set CONFIG_MCS_FIR=y CONFIG_BT=y # CONFIG_BT_L2CAP is not set # CONFIG_BT_SCO is not set # # Bluetooth device drivers # CONFIG_BT_HCIUSB=y CONFIG_BT_HCIUSB_SCO=y CONFIG_BT_HCIUART=y CONFIG_BT_HCIUART_H4=y # CONFIG_BT_HCIUART_BCSP is not set # CONFIG_BT_HCIUART_LL is not set # CONFIG_BT_HCIBCM203X is not set CONFIG_BT_HCIBPA10X=y CONFIG_BT_HCIBFUSB=y CONFIG_BT_HCIVHCI=y CONFIG_AF_RXRPC=y CONFIG_AF_RXRPC_DEBUG=y CONFIG_RXKAD=y CONFIG_FIB_RULES=y # # Wireless # # CONFIG_CFG80211 is not set CONFIG_WIRELESS_EXT=y # CONFIG_MAC80211 is not set CONFIG_IEEE80211=y CONFIG_IEEE80211_DEBUG=y CONFIG_IEEE80211_CRYPT_WEP=y CONFIG_IEEE80211_CRYPT_CCMP=y # CONFIG_IEEE80211_CRYPT_TKIP is not set # CONFIG_IEEE80211_SOFTMAC is not set CONFIG_RFKILL=y # CONFIG_RFKILL_INPUT is not set CONFIG_NET_9P=y # CONFIG_NET_9P_FD is not set # CONFIG_NET_9P_DEBUG is not set # # Device Drivers # # # Generic Driver Options # CONFIG_UEVENT_HELPER_PATH="/sbin/hotplug" CONFIG_STANDALONE=y CONFIG_PREVENT_FIRMWARE_BUILD=y CONFIG_FW_LOADER=y CONFIG_DEBUG_DRIVER=y # CONFIG_DEBUG_DEVRES is not set # CONFIG_SYS_HYPERVISOR is not set CONFIG_CONNECTOR=y CONFIG_PROC_EVENTS=y # CONFIG_MTD is not set CONFIG_PARPORT=y # CONFIG_PARPORT_PC is not set # CONFIG_PARPORT_GSC is not set # CONFIG_PARPORT_AX88796 is not set CONFIG_PARPORT_1284=y CONFIG_PARPORT_NOT_PC=y CONFIG_PNP=y # CONFIG_PNP_DEBUG is not set # # Protocols # CONFIG_PNPACPI=y CONFIG_BLK_DEV=y CONFIG_BLK_DEV_FD=y CONFIG_BLK_CPQ_DA=y # CONFIG_BLK_CPQ_CISS_DA is not set CONFIG_BLK_DEV_DAC960=y # CONFIG_BLK_DEV_UMEM is not set # CONFIG_BLK_DEV_COW_COMMON is not set CONFIG_BLK_DEV_LOOP=y # CONFIG_BLK_DEV_CRYPTOLOOP is not set CONFIG_BLK_DEV_NBD=y # CONFIG_BLK_DEV_SX8 is not set # CONFIG_BLK_DEV_UB is not set # CONFIG_BLK_DEV_RAM is not set CONFIG_CDROM_PKTCDVD=y CONFIG_CDROM_PKTCDVD_BUFFERS=8 CONFIG_CDROM_PKTCDVD_WCACHE=y # CONFIG_ATA_OVER_ETH is not set # CONFIG_MISC_DEVICES is not set # CONFIG_IDE is not set # # SCSI device support # # CONFIG_RAID_ATTRS is not set CONFIG_SCSI=y CONFIG_SCSI_DMA=y CONFIG_SCSI_TGT=y CONFIG_SCSI_NETLINK=y CONFIG_SCSI_PROC_FS=y # # SCSI support type (disk, tape, CD-ROM) # CONFIG_BLK_DEV_SD=y CONFIG_CHR_DEV_ST=y CONFIG_CHR_DEV_OSST=y # CONFIG_BLK_DEV_SR is not set # CONFIG_CHR_DEV_SG is not set CONFIG_CHR_DEV_SCH=y # # Some SCSI devices (e.g. CD jukebox) support multiple LUNs # # CONFIG_SCSI_MULTI_LUN is not set # CONFIG_SCSI_CONSTANTS is not set # CONFIG_SCSI_LOGGING is not set # CONFIG_SCSI_SCAN_ASYNC is not set # # SCSI Transports # CONFIG_SCSI_SPI_ATTRS=y CONFIG_SCSI_FC_ATTRS=y CONFIG_SCSI_FC_TGT_ATTRS=y CONFIG_SCSI_ISCSI_ATTRS=y CONFIG_SCSI_SAS_ATTRS=y CONFIG_SCSI_SAS_LIBSAS=y # CONFIG_SCSI_SAS_ATA is not set # CONFIG_SCSI_SAS_LIBSAS_DEBUG is not set # CONFIG_SCSI_SRP_ATTRS is not set # CONFIG_SCSI_LOWLEVEL is not set CONFIG_ATA=y # CONFIG_ATA_NONSTANDARD is not set CONFIG_ATA_ACPI=y CONFIG_SATA_AHCI=y # CONFIG_SATA_SVW is not set CONFIG_ATA_PIIX=y CONFIG_SATA_MV=y # CONFIG_SATA_NV is not set # CONFIG_PDC_ADMA is not set CONFIG_SATA_QSTOR=y # CONFIG_SATA_PROMISE is not set # CONFIG_SATA_SX4 is not set CONFIG_SATA_SIL=y # CONFIG_SATA_SIL24 is not set # CONFIG_SATA_SIS is not set CONFIG_SATA_ULI=y # CONFIG_SATA_VIA is not set CONFIG_SATA_VITESSE=y CONFIG_SATA_INIC162X=y # CONFIG_PATA_ACPI is not set CONFIG_PATA_ALI=y CONFIG_PATA_AMD=y CONFIG_PATA_ARTOP=y CONFIG_PATA_ATIIXP=y # CONFIG_PATA_CMD640_PCI is not set # CONFIG_PATA_CMD64X is not set CONFIG_PATA_CS5520=y # CONFIG_PATA_CS5530 is not set CONFIG_PATA_CS5535=y # CONFIG_PATA_CS5536 is not set # CONFIG_PATA_CYPRESS is not set CONFIG_PATA_EFAR=y # CONFIG_ATA_GENERIC is not set # CONFIG_PATA_HPT366 is not set CONFIG_PATA_HPT37X=y # CONFIG_PATA_HPT3X2N is not set CONFIG_PATA_HPT3X3=y CONFIG_PATA_HPT3X3_DMA=y # CONFIG_PATA_IT821X is not set CONFIG_PATA_IT8213=y CONFIG_PATA_JMICRON=y CONFIG_PATA_TRIFLEX=y CONFIG_PATA_MARVELL=y CONFIG_PATA_MPIIX=y CONFIG_PATA_OLDPIIX=y # CONFIG_PATA_NETCELL is not set CONFIG_PATA_NS87410=y # CONFIG_PATA_NS87415 is not set CONFIG_PATA_OPTI=y CONFIG_PATA_OPTIDMA=y CONFIG_PATA_PDC_OLD=y CONFIG_PATA_RADISYS=y # CONFIG_PATA_RZ1000 is not set CONFIG_PATA_SC1200=y CONFIG_PATA_SERVERWORKS=y CONFIG_PATA_PDC2027X=y # CONFIG_PATA_SIL680 is not set # CONFIG_PATA_SIS is not set CONFIG_PATA_VIA=y # CONFIG_PATA_WINBOND is not set CONFIG_MD=y # CONFIG_BLK_DEV_MD is not set CONFIG_BLK_DEV_DM=y # CONFIG_DM_DEBUG is not set CONFIG_DM_CRYPT=y CONFIG_DM_SNAPSHOT=y # CONFIG_DM_MIRROR is not set # CONFIG_DM_ZERO is not set CONFIG_DM_MULTIPATH=y # CONFIG_DM_MULTIPATH_EMC is not set # CONFIG_DM_MULTIPATH_RDAC is not set # CONFIG_DM_MULTIPATH_HP is not set # CONFIG_DM_DELAY is not set CONFIG_DM_UEVENT=y # CONFIG_FUSION is not set # # IEEE 1394 (FireWire) support # CONFIG_FIREWIRE=y CONFIG_FIREWIRE_OHCI=y CONFIG_FIREWIRE_SBP2=y # CONFIG_IEEE1394 is not set # CONFIG_I2O is not set CONFIG_MACINTOSH_DRIVERS=y # CONFIG_MAC_EMUMOUSEBTN is not set CONFIG_NETDEVICES=y # CONFIG_NETDEVICES_MULTIQUEUE is not set # CONFIG_DUMMY is not set CONFIG_BONDING=y CONFIG_MACVLAN=y # CONFIG_EQUALIZER is not set CONFIG_TUN=y CONFIG_VETH=y CONFIG_NET_SB1000=y # CONFIG_ARCNET is not set CONFIG_PHYLIB=y # # MII PHY device drivers # CONFIG_MARVELL_PHY=y CONFIG_DAVICOM_PHY=y # CONFIG_QSEMI_PHY is not set CONFIG_LXT_PHY=y CONFIG_CICADA_PHY=y # CONFIG_VITESSE_PHY is not set # CONFIG_SMSC_PHY is not set # CONFIG_BROADCOM_PHY is not set # CONFIG_ICPLUS_PHY is not set # CONFIG_FIXED_PHY is not set # CONFIG_MDIO_BITBANG is not set CONFIG_NET_ETHERNET=y CONFIG_MII=y CONFIG_HAPPYMEAL=y # CONFIG_SUNGEM is not set CONFIG_CASSINI=y # CONFIG_NET_VENDOR_3COM is not set CONFIG_NET_VENDOR_SMC=y CONFIG_ULTRAMCA=y CONFIG_NET_TULIP=y CONFIG_DE2104X=y CONFIG_TULIP=y CONFIG_TULIP_MWI=y # CONFIG_TULIP_MMIO is not set # CONFIG_TULIP_NAPI is not set # CONFIG_DE4X5 is not set CONFIG_WINBOND_840=y CONFIG_DM9102=y # CONFIG_ULI526X is not set CONFIG_PCMCIA_XIRCOM=y # CONFIG_AT1700 is not set CONFIG_DEPCA=y # CONFIG_HP100 is not set # CONFIG_NE2_MCA is not set CONFIG_IBMLANA=y # CONFIG_IBM_NEW_EMAC_ZMII is not set # CONFIG_IBM_NEW_EMAC_RGMII is not set # CONFIG_IBM_NEW_EMAC_TAH is not set # CONFIG_IBM_NEW_EMAC_EMAC4 is not set CONFIG_NET_PCI=y CONFIG_PCNET32=y CONFIG_PCNET32_NAPI=y # CONFIG_AMD8111_ETH is not set # CONFIG_ADAPTEC_STARFIRE is not set # CONFIG_B44 is not set CONFIG_FORCEDETH=y CONFIG_FORCEDETH_NAPI=y # CONFIG_EEPRO100 is not set CONFIG_E100=y CONFIG_FEALNX=y # CONFIG_NATSEMI is not set CONFIG_NE2K_PCI=y # CONFIG_8139CP is not set CONFIG_8139TOO=y CONFIG_8139TOO_PIO=y # CONFIG_8139TOO_TUNE_TWISTER is not set CONFIG_8139TOO_8129=y CONFIG_8139_OLD_RX_RESET=y # CONFIG_SIS900 is not set CONFIG_EPIC100=y # CONFIG_SUNDANCE is not set # CONFIG_TLAN is not set CONFIG_VIA_RHINE=y CONFIG_VIA_RHINE_MMIO=y CONFIG_VIA_RHINE_NAPI=y # CONFIG_SC92031 is not set # CONFIG_NET_POCKET is not set CONFIG_NETDEV_1000=y CONFIG_ACENIC=y # CONFIG_ACENIC_OMIT_TIGON_I is not set # CONFIG_DL2K is not set CONFIG_E1000=y CONFIG_E1000_NAPI=y # CONFIG_E1000_DISABLE_PACKET_SPLIT is not set # CONFIG_E1000E is not set CONFIG_IP1000=y # CONFIG_NS83820 is not set # CONFIG_HAMACHI is not set # CONFIG_YELLOWFIN is not set CONFIG_R8169=y # CONFIG_R8169_NAPI is not set CONFIG_SIS190=y # CONFIG_SKGE is not set CONFIG_SKY2=y CONFIG_SKY2_DEBUG=y CONFIG_SK98LIN=y CONFIG_VIA_VELOCITY=y CONFIG_TIGON3=y CONFIG_BNX2=y CONFIG_QLA3XXX=y CONFIG_ATL1=y CONFIG_NETDEV_10000=y # CONFIG_CHELSIO_T1 is not set # CONFIG_CHELSIO_T3 is not set CONFIG_IXGBE=y CONFIG_IXGB=y CONFIG_IXGB_NAPI=y # CONFIG_S2IO is not set # CONFIG_MYRI10GE is not set CONFIG_NETXEN_NIC=y CONFIG_NIU=y # CONFIG_MLX4_CORE is not set CONFIG_TEHUTI=y # CONFIG_TR is not set # # Wireless LAN # CONFIG_WLAN_PRE80211=y # CONFIG_STRIP is not set CONFIG_WLAN_80211=y CONFIG_IPW2100=y CONFIG_IPW2100_MONITOR=y CONFIG_IPW2100_DEBUG=y # CONFIG_IPW2200 is not set # CONFIG_LIBERTAS is not set CONFIG_AIRO=y # CONFIG_HERMES is not set # CONFIG_ATMEL is not set CONFIG_PRISM54=y CONFIG_USB_ZD1201=y # CONFIG_HOSTAP is not set # # USB Network Adapters # CONFIG_USB_CATC=y # CONFIG_USB_KAWETH is not set # CONFIG_USB_PEGASUS is not set CONFIG_USB_RTL8150=y CONFIG_USB_USBNET=y # CONFIG_USB_NET_AX8817X is not set CONFIG_USB_NET_CDCETHER=y # CONFIG_USB_NET_DM9601 is not set # CONFIG_USB_NET_GL620A is not set CONFIG_USB_NET_NET1080=y # CONFIG_USB_NET_PLUSB is not set # CONFIG_USB_NET_MCS7830 is not set # CONFIG_USB_NET_RNDIS_HOST is not set # CONFIG_USB_NET_CDC_SUBSET is not set CONFIG_USB_NET_ZAURUS=y CONFIG_WAN=y # CONFIG_LANMEDIA is not set CONFIG_HDLC=y # CONFIG_HDLC_RAW is not set CONFIG_HDLC_RAW_ETH=y # CONFIG_HDLC_CISCO is not set CONFIG_HDLC_FR=y # CONFIG_HDLC_PPP is not set CONFIG_HDLC_X25=y # CONFIG_PCI200SYN is not set CONFIG_WANXL=y CONFIG_PC300=y # # Cyclades-PC300 MLPPP support is disabled. # # # Refer to the file README.mlppp, provided by PC300 package. # CONFIG_PC300TOO=y # CONFIG_FARSYNC is not set # CONFIG_DLCI is not set CONFIG_SBNI=y # CONFIG_SBNI_MULTILINE is not set CONFIG_FDDI=y CONFIG_DEFXX=y CONFIG_DEFXX_MMIO=y # CONFIG_SKFP is not set CONFIG_HIPPI=y # CONFIG_ROADRUNNER is not set # CONFIG_PLIP is not set # CONFIG_PPP is not set # CONFIG_SLIP is not set # CONFIG_NET_FC is not set CONFIG_SHAPER=y CONFIG_NETCONSOLE=y # CONFIG_NETCONSOLE_DYNAMIC is not set CONFIG_NETPOLL=y # CONFIG_NETPOLL_TRAP is not set CONFIG_NET_POLL_CONTROLLER=y CONFIG_ISDN=y # CONFIG_ISDN_I4L is not set CONFIG_ISDN_CAPI=y # CONFIG_ISDN_DRV_AVMB1_VERBOSE_REASON is not set # CONFIG_CAPI_TRACE is not set CONFIG_ISDN_CAPI_MIDDLEWARE=y CONFIG_ISDN_CAPI_CAPI20=y CONFIG_ISDN_CAPI_CAPIFS_BOOL=y CONFIG_ISDN_CAPI_CAPIFS=y # # CAPI hardware drivers # CONFIG_CAPI_AVM=y # CONFIG_ISDN_DRV_AVMB1_B1PCI is not set # CONFIG_ISDN_DRV_AVMB1_B1PCMCIA is not set # CONFIG_ISDN_DRV_AVMB1_T1PCI is not set # CONFIG_ISDN_DRV_AVMB1_C4 is not set # CONFIG_CAPI_EICON is not set # CONFIG_PHONE is not set # # Input device support # CONFIG_INPUT=y CONFIG_INPUT_FF_MEMLESS=y CONFIG_INPUT_POLLDEV=y # # Userland interfaces # CONFIG_INPUT_MOUSEDEV=y CONFIG_INPUT_MOUSEDEV_PSAUX=y CONFIG_INPUT_MOUSEDEV_SCREEN_X=1024 CONFIG_INPUT_MOUSEDEV_SCREEN_Y=768 # CONFIG_INPUT_JOYDEV is not set CONFIG_INPUT_EVDEV=y # CONFIG_INPUT_EVBUG is not set # # Input Device Drivers # CONFIG_INPUT_KEYBOARD=y CONFIG_KEYBOARD_ATKBD=y # CONFIG_KEYBOARD_SUNKBD is not set # CONFIG_KEYBOARD_LKKBD is not set CONFIG_KEYBOARD_XTKBD=y # CONFIG_KEYBOARD_NEWTON is not set CONFIG_KEYBOARD_STOWAWAY=y CONFIG_INPUT_MOUSE=y # CONFIG_MOUSE_PS2 is not set # CONFIG_MOUSE_SERIAL is not set # CONFIG_MOUSE_APPLETOUCH is not set # CONFIG_MOUSE_VSXXXAA is not set # CONFIG_INPUT_JOYSTICK is not set CONFIG_INPUT_TABLET=y # CONFIG_TABLET_USB_ACECAD is not set CONFIG_TABLET_USB_AIPTEK=y CONFIG_TABLET_USB_GTCO=y CONFIG_TABLET_USB_KBTAB=y # CONFIG_TABLET_USB_WACOM is not set CONFIG_INPUT_TOUCHSCREEN=y CONFIG_TOUCHSCREEN_FUJITSU=y CONFIG_TOUCHSCREEN_GUNZE=y CONFIG_TOUCHSCREEN_ELO=y CONFIG_TOUCHSCREEN_MTOUCH=y # CONFIG_TOUCHSCREEN_MK712 is not set CONFIG_TOUCHSCREEN_PENMOUNT=y CONFIG_TOUCHSCREEN_TOUCHRIGHT=y # CONFIG_TOUCHSCREEN_TOUCHWIN is not set CONFIG_TOUCHSCREEN_UCB1400=y CONFIG_TOUCHSCREEN_USB_COMPOSITE=y CONFIG_TOUCHSCREEN_USB_EGALAX=y CONFIG_TOUCHSCREEN_USB_PANJIT=y CONFIG_TOUCHSCREEN_USB_3M=y CONFIG_TOUCHSCREEN_USB_ITM=y CONFIG_TOUCHSCREEN_USB_ETURBO=y CONFIG_TOUCHSCREEN_USB_GUNZE=y CONFIG_TOUCHSCREEN_USB_DMC_TSC10=y CONFIG_TOUCHSCREEN_USB_IRTOUCH=y CONFIG_TOUCHSCREEN_USB_IDEALTEK=y CONFIG_TOUCHSCREEN_USB_GENERAL_TOUCH=y CONFIG_TOUCHSCREEN_USB_GOTOP=y CONFIG_INPUT_MISC=y # CONFIG_INPUT_PCSPKR is not set CONFIG_INPUT_WISTRON_BTNS=y CONFIG_INPUT_ATLAS_BTNS=y CONFIG_INPUT_ATI_REMOTE=y # CONFIG_INPUT_ATI_REMOTE2 is not set CONFIG_INPUT_KEYSPAN_REMOTE=y # CONFIG_INPUT_POWERMATE is not set CONFIG_INPUT_YEALINK=y CONFIG_INPUT_UINPUT=y # # Hardware I/O ports # CONFIG_SERIO=y CONFIG_SERIO_I8042=y CONFIG_SERIO_SERPORT=y # CONFIG_SERIO_CT82C710 is not set CONFIG_SERIO_PARKBD=y CONFIG_SERIO_PCIPS2=y CONFIG_SERIO_LIBPS2=y CONFIG_SERIO_RAW=y # CONFIG_GAMEPORT is not set # # Character devices # CONFIG_VT=y CONFIG_VT_CONSOLE=y CONFIG_HW_CONSOLE=y CONFIG_VT_HW_CONSOLE_BINDING=y # CONFIG_SERIAL_NONSTANDARD is not set # # Serial drivers # CONFIG_SERIAL_8250=y CONFIG_SERIAL_8250_CONSOLE=y CONFIG_FIX_EARLYCON_MEM=y CONFIG_SERIAL_8250_PCI=y CONFIG_SERIAL_8250_PNP=y CONFIG_SERIAL_8250_NR_UARTS=4 CONFIG_SERIAL_8250_RUNTIME_UARTS=4 # CONFIG_SERIAL_8250_EXTENDED is not set # CONFIG_SERIAL_8250_MCA is not set # # Non-8250 serial port support # CONFIG_SERIAL_CORE=y CONFIG_SERIAL_CORE_CONSOLE=y # CONFIG_SERIAL_JSM is not set CONFIG_UNIX98_PTYS=y # CONFIG_LEGACY_PTYS is not set # CONFIG_PRINTER is not set CONFIG_PPDEV=y CONFIG_IPMI_HANDLER=y CONFIG_IPMI_PANIC_EVENT=y CONFIG_IPMI_PANIC_STRING=y # CONFIG_IPMI_DEVICE_INTERFACE is not set # CONFIG_IPMI_SI is not set # CONFIG_IPMI_WATCHDOG is not set # CONFIG_IPMI_POWEROFF is not set CONFIG_HW_RANDOM=y # CONFIG_HW_RANDOM_INTEL is not set CONFIG_HW_RANDOM_AMD=y # CONFIG_HW_RANDOM_GEODE is not set CONFIG_HW_RANDOM_VIA=y CONFIG_NVRAM=y CONFIG_RTC=y # CONFIG_R3964 is not set # CONFIG_APPLICOM is not set CONFIG_SONYPI=y CONFIG_MWAVE=y # CONFIG_SCx200_GPIO is not set CONFIG_PC8736x_GPIO=y CONFIG_NSC_GPIO=y CONFIG_CS5535_GPIO=y # CONFIG_RAW_DRIVER is not set CONFIG_HPET=y CONFIG_HPET_RTC_IRQ=y # CONFIG_HPET_MMAP is not set # CONFIG_HANGCHECK_TIMER is not set # CONFIG_TCG_TPM is not set CONFIG_TELCLOCK=y CONFIG_DEVPORT=y CONFIG_I2C=y CONFIG_I2C_BOARDINFO=y # CONFIG_I2C_CHARDEV is not set # # I2C Algorithms # CONFIG_I2C_ALGOBIT=y CONFIG_I2C_ALGOPCF=y # CONFIG_I2C_ALGOPCA is not set # # I2C Hardware Bus support # CONFIG_I2C_ALI1535=y # CONFIG_I2C_ALI1563 is not set CONFIG_I2C_ALI15X3=y CONFIG_I2C_AMD756=y # CONFIG_I2C_AMD756_S4882 is not set # CONFIG_I2C_AMD8111 is not set CONFIG_I2C_I801=y # CONFIG_I2C_I810 is not set CONFIG_I2C_PIIX4=y CONFIG_I2C_NFORCE2=y # CONFIG_I2C_OCORES is not set # CONFIG_I2C_PARPORT is not set CONFIG_I2C_PARPORT_LIGHT=y CONFIG_I2C_PROSAVAGE=y # CONFIG_I2C_SAVAGE4 is not set # CONFIG_I2C_SIMTEC is not set # CONFIG_SCx200_ACB is not set # CONFIG_I2C_SIS5595 is not set # CONFIG_I2C_SIS630 is not set CONFIG_I2C_SIS96X=y CONFIG_I2C_TAOS_EVM=y # CONFIG_I2C_TINY_USB is not set CONFIG_I2C_VIA=y # CONFIG_I2C_VIAPRO is not set CONFIG_I2C_VOODOO3=y # # Miscellaneous I2C Chip support # CONFIG_SENSORS_DS1337=y # CONFIG_SENSORS_DS1374 is not set # CONFIG_DS1682 is not set # CONFIG_SENSORS_EEPROM is not set CONFIG_SENSORS_PCF8574=y # CONFIG_SENSORS_PCA9539 is not set CONFIG_SENSORS_PCF8591=y CONFIG_SENSORS_MAX6875=y # CONFIG_SENSORS_TSL2550 is not set CONFIG_I2C_DEBUG_CORE=y # CONFIG_I2C_DEBUG_ALGO is not set # CONFIG_I2C_DEBUG_BUS is not set CONFIG_I2C_DEBUG_CHIP=y # # SPI support # # CONFIG_SPI is not set # CONFIG_SPI_MASTER is not set # CONFIG_W1 is not set CONFIG_POWER_SUPPLY=y # CONFIG_POWER_SUPPLY_DEBUG is not set # CONFIG_PDA_POWER is not set # CONFIG_BATTERY_DS2760 is not set # CONFIG_HWMON is not set CONFIG_WATCHDOG=y # CONFIG_WATCHDOG_NOWAYOUT is not set # # Watchdog Device Drivers # # CONFIG_SOFT_WATCHDOG is not set CONFIG_ACQUIRE_WDT=y # CONFIG_ADVANTECH_WDT is not set # CONFIG_ALIM1535_WDT is not set CONFIG_ALIM7101_WDT=y CONFIG_SC520_WDT=y # CONFIG_EUROTECH_WDT is not set # CONFIG_IB700_WDT is not set CONFIG_IBMASR=y # CONFIG_WAFER_WDT is not set # CONFIG_I6300ESB_WDT is not set # CONFIG_ITCO_WDT is not set # CONFIG_IT8712F_WDT is not set # CONFIG_SC1200_WDT is not set # CONFIG_SCx200_WDT is not set CONFIG_PC87413_WDT=y CONFIG_60XX_WDT=y # CONFIG_SBC8360_WDT is not set CONFIG_SBC7240_WDT=y CONFIG_CPU5_WDT=y # CONFIG_SMSC37B787_WDT is not set CONFIG_W83627HF_WDT=y CONFIG_W83697HF_WDT=y CONFIG_W83877F_WDT=y CONFIG_W83977F_WDT=y # CONFIG_MACHZ_WDT is not set CONFIG_SBC_EPX_C3_WATCHDOG=y # # PCI-based Watchdog Cards # CONFIG_PCIPCWATCHDOG=y CONFIG_WDTPCI=y CONFIG_WDT_501_PCI=y # # USB-based Watchdog Cards # # CONFIG_USBPCWATCHDOG is not set # # Sonics Silicon Backplane # CONFIG_SSB_POSSIBLE=y CONFIG_SSB=y CONFIG_SSB_PCIHOST_POSSIBLE=y # CONFIG_SSB_PCIHOST is not set CONFIG_SSB_DEBUG=y # # Multifunction device drivers # # CONFIG_MFD_SM501 is not set # # Multimedia devices # # CONFIG_VIDEO_DEV is not set # CONFIG_DVB_CORE is not set # CONFIG_DAB is not set # # Graphics support # # CONFIG_AGP is not set CONFIG_DRM=y # CONFIG_DRM_TDFX is not set CONFIG_DRM_R128=y CONFIG_DRM_RADEON=y CONFIG_DRM_MGA=y # CONFIG_DRM_VIA is not set CONFIG_DRM_SAVAGE=y # CONFIG_VGASTATE is not set # CONFIG_VIDEO_OUTPUT_CONTROL is not set # CONFIG_FB is not set CONFIG_BACKLIGHT_LCD_SUPPORT=y # CONFIG_LCD_CLASS_DEVICE is not set CONFIG_BACKLIGHT_CLASS_DEVICE=y # CONFIG_BACKLIGHT_CORGI is not set # CONFIG_BACKLIGHT_PROGEAR is not set # # Display device support # CONFIG_DISPLAY_SUPPORT=y # # Display hardware drivers # # # Console display driver support # CONFIG_VGA_CONSOLE=y CONFIG_VGACON_SOFT_SCROLLBACK=y CONFIG_VGACON_SOFT_SCROLLBACK_SIZE=64 CONFIG_VIDEO_SELECT=y CONFIG_DUMMY_CONSOLE=y # # Sound # # CONFIG_SOUND is not set CONFIG_AC97_BUS=y CONFIG_HID_SUPPORT=y CONFIG_HID=y CONFIG_HID_DEBUG=y # CONFIG_HIDRAW is not set # # USB Input Devices # # CONFIG_USB_HID is not set # # USB HID Boot Protocol drivers # CONFIG_USB_KBD=y CONFIG_USB_MOUSE=y CONFIG_USB_SUPPORT=y CONFIG_USB_ARCH_HAS_HCD=y CONFIG_USB_ARCH_HAS_OHCI=y CONFIG_USB_ARCH_HAS_EHCI=y CONFIG_USB=y CONFIG_USB_DEBUG=y # # Miscellaneous USB options # CONFIG_USB_DEVICEFS=y CONFIG_USB_DEVICE_CLASS=y CONFIG_USB_DYNAMIC_MINORS=y CONFIG_USB_SUSPEND=y # CONFIG_USB_PERSIST is not set # CONFIG_USB_OTG is not set # # USB Host Controller Drivers # CONFIG_USB_EHCI_HCD=y CONFIG_USB_EHCI_SPLIT_ISO=y # CONFIG_USB_EHCI_ROOT_HUB_TT is not set CONFIG_USB_EHCI_TT_NEWSCHED=y CONFIG_USB_ISP116X_HCD=y CONFIG_USB_OHCI_HCD=y # CONFIG_USB_OHCI_HCD_SSB is not set # CONFIG_USB_OHCI_BIG_ENDIAN_DESC is not set # CONFIG_USB_OHCI_BIG_ENDIAN_MMIO is not set CONFIG_USB_OHCI_LITTLE_ENDIAN=y CONFIG_USB_UHCI_HCD=y CONFIG_USB_U132_HCD=y CONFIG_USB_SL811_HCD=y CONFIG_USB_R8A66597_HCD=y # # USB Device Class drivers # # CONFIG_USB_ACM is not set CONFIG_USB_PRINTER=y # # NOTE: USB_STORAGE enables SCSI, and 'SCSI disk support' # # # may also be needed; see USB_STORAGE Help for more information # CONFIG_USB_STORAGE=y CONFIG_USB_STORAGE_DEBUG=y # CONFIG_USB_STORAGE_DATAFAB is not set # CONFIG_USB_STORAGE_FREECOM is not set # CONFIG_USB_STORAGE_ISD200 is not set # CONFIG_USB_STORAGE_DPCM is not set CONFIG_USB_STORAGE_USBAT=y # CONFIG_USB_STORAGE_SDDR09 is not set # CONFIG_USB_STORAGE_SDDR55 is not set # CONFIG_USB_STORAGE_JUMPSHOT is not set CONFIG_USB_STORAGE_ALAUDA=y CONFIG_USB_STORAGE_KARMA=y # CONFIG_USB_LIBUSUAL is not set # # USB Imaging devices # CONFIG_USB_MDC800=y # CONFIG_USB_MICROTEK is not set CONFIG_USB_MON=y # # USB port drivers # CONFIG_USB_USS720=y # # USB Serial Converter support # CONFIG_USB_SERIAL=y # CONFIG_USB_SERIAL_CONSOLE is not set # CONFIG_USB_SERIAL_GENERIC is not set CONFIG_USB_SERIAL_AIRCABLE=y # CONFIG_USB_SERIAL_AIRPRIME is not set CONFIG_USB_SERIAL_ARK3116=y # CONFIG_USB_SERIAL_BELKIN is not set CONFIG_USB_SERIAL_CH341=y # CONFIG_USB_SERIAL_WHITEHEAT is not set CONFIG_USB_SERIAL_DIGI_ACCELEPORT=y CONFIG_USB_SERIAL_CP2101=y # CONFIG_USB_SERIAL_CYPRESS_M8 is not set CONFIG_USB_SERIAL_EMPEG=y # CONFIG_USB_SERIAL_FTDI_SIO is not set # CONFIG_USB_SERIAL_FUNSOFT is not set # CONFIG_USB_SERIAL_VISOR is not set # CONFIG_USB_SERIAL_IPAQ is not set # CONFIG_USB_SERIAL_IR is not set CONFIG_USB_SERIAL_EDGEPORT=y CONFIG_USB_SERIAL_EDGEPORT_TI=y # CONFIG_USB_SERIAL_GARMIN is not set CONFIG_USB_SERIAL_IPW=y # CONFIG_USB_SERIAL_KEYSPAN_PDA is not set CONFIG_USB_SERIAL_KEYSPAN=y # CONFIG_USB_SERIAL_KEYSPAN_MPR is not set # CONFIG_USB_SERIAL_KEYSPAN_USA28 is not set CONFIG_USB_SERIAL_KEYSPAN_USA28X=y # CONFIG_USB_SERIAL_KEYSPAN_USA28XA is not set CONFIG_USB_SERIAL_KEYSPAN_USA28XB=y CONFIG_USB_SERIAL_KEYSPAN_USA19=y # CONFIG_USB_SERIAL_KEYSPAN_USA18X is not set CONFIG_USB_SERIAL_KEYSPAN_USA19W=y CONFIG_USB_SERIAL_KEYSPAN_USA19QW=y # CONFIG_USB_SERIAL_KEYSPAN_USA19QI is not set CONFIG_USB_SERIAL_KEYSPAN_USA49W=y CONFIG_USB_SERIAL_KEYSPAN_USA49WLC=y # CONFIG_USB_SERIAL_KLSI is not set CONFIG_USB_SERIAL_KOBIL_SCT=y CONFIG_USB_SERIAL_MCT_U232=y # CONFIG_USB_SERIAL_MOS7720 is not set CONFIG_USB_SERIAL_MOS7840=y # CONFIG_USB_SERIAL_NAVMAN is not set CONFIG_USB_SERIAL_PL2303=y # CONFIG_USB_SERIAL_OTI6858 is not set CONFIG_USB_SERIAL_HP4X=y # CONFIG_USB_SERIAL_SAFE is not set # CONFIG_USB_SERIAL_SIERRAWIRELESS is not set CONFIG_USB_SERIAL_TI=y CONFIG_USB_SERIAL_CYBERJACK=y # CONFIG_USB_SERIAL_XIRCOM is not set CONFIG_USB_SERIAL_OPTION=y # CONFIG_USB_SERIAL_OMNINET is not set # CONFIG_USB_SERIAL_DEBUG is not set CONFIG_USB_EZUSB=y # # USB Miscellaneous drivers # CONFIG_USB_EMI62=y # CONFIG_USB_EMI26 is not set CONFIG_USB_ADUTUX=y CONFIG_USB_AUERSWALD=y CONFIG_USB_RIO500=y # CONFIG_USB_LEGOTOWER is not set # CONFIG_USB_LCD is not set # CONFIG_USB_BERRY_CHARGE is not set CONFIG_USB_LED=y CONFIG_USB_CYPRESS_CY7C63=y CONFIG_USB_CYTHERM=y # CONFIG_USB_PHIDGET is not set # CONFIG_USB_IDMOUSE is not set CONFIG_USB_FTDI_ELAN=y CONFIG_USB_APPLEDISPLAY=y CONFIG_USB_SISUSBVGA=y # CONFIG_USB_SISUSBVGA_CON is not set # CONFIG_USB_LD is not set CONFIG_USB_TRANCEVIBRATOR=y CONFIG_USB_IOWARRIOR=y CONFIG_USB_TEST=y # # USB DSL modem support # # # USB Gadget Support # # CONFIG_USB_GADGET is not set # CONFIG_MMC is not set CONFIG_NEW_LEDS=y CONFIG_LEDS_CLASS=y # # LED drivers # # # LED Triggers # # CONFIG_LEDS_TRIGGERS is not set CONFIG_INFINIBAND=y # CONFIG_INFINIBAND_USER_MAD is not set # CONFIG_INFINIBAND_USER_ACCESS is not set CONFIG_INFINIBAND_ADDR_TRANS=y # CONFIG_INFINIBAND_MTHCA is not set CONFIG_INFINIBAND_AMSO1100=y # CONFIG_INFINIBAND_AMSO1100_DEBUG is not set # CONFIG_MLX4_INFINIBAND is not set CONFIG_INFINIBAND_IPOIB=y CONFIG_INFINIBAND_IPOIB_CM=y CONFIG_INFINIBAND_IPOIB_DEBUG=y # CONFIG_INFINIBAND_IPOIB_DEBUG_DATA is not set # CONFIG_INFINIBAND_SRP is not set CONFIG_INFINIBAND_ISER=y # CONFIG_EDAC is not set CONFIG_RTC_LIB=y CONFIG_RTC_CLASS=y # CONFIG_RTC_HCTOSYS is not set # CONFIG_RTC_DEBUG is not set # # RTC interfaces # # CONFIG_RTC_INTF_SYSFS is not set # CONFIG_RTC_INTF_PROC is not set CONFIG_RTC_INTF_DEV=y CONFIG_RTC_INTF_DEV_UIE_EMUL=y CONFIG_RTC_DRV_TEST=y # # I2C RTC drivers # # CONFIG_RTC_DRV_DS1307 is not set # CONFIG_RTC_DRV_DS1374 is not set CONFIG_RTC_DRV_DS1672=y CONFIG_RTC_DRV_MAX6900=y CONFIG_RTC_DRV_RS5C372=y # CONFIG_RTC_DRV_ISL1208 is not set # CONFIG_RTC_DRV_X1205 is not set # CONFIG_RTC_DRV_PCF8563 is not set CONFIG_RTC_DRV_PCF8583=y CONFIG_RTC_DRV_M41T80=y # CONFIG_RTC_DRV_M41T80_WDT is not set # # SPI RTC drivers # # # Platform RTC drivers # CONFIG_RTC_DRV_CMOS=y CONFIG_RTC_DRV_DS1553=y # CONFIG_RTC_DRV_STK17TA8 is not set # CONFIG_RTC_DRV_DS1742 is not set CONFIG_RTC_DRV_M48T86=y CONFIG_RTC_DRV_M48T59=y CONFIG_RTC_DRV_V3020=y # # on-CPU RTC drivers # CONFIG_DMADEVICES=y # # DMA Devices # # CONFIG_INTEL_IOATDMA is not set CONFIG_AUXDISPLAY=y # CONFIG_VIRTUALIZATION is not set # # Userspace I/O # # CONFIG_UIO is not set # # Firmware Drivers # # CONFIG_EDD is not set # CONFIG_DELL_RBU is not set # CONFIG_DCDBAS is not set CONFIG_DMIID=y # # File systems # # CONFIG_EXT2_FS is not set CONFIG_EXT3_FS=y CONFIG_EXT3_FS_XATTR=y CONFIG_EXT3_FS_POSIX_ACL=y CONFIG_EXT3_FS_SECURITY=y # CONFIG_EXT4DEV_FS is not set CONFIG_JBD=y CONFIG_JBD_DEBUG=y CONFIG_FS_MBCACHE=y # CONFIG_REISERFS_FS is not set CONFIG_JFS_FS=y # CONFIG_JFS_POSIX_ACL is not set CONFIG_JFS_SECURITY=y # CONFIG_JFS_DEBUG is not set # CONFIG_JFS_STATISTICS is not set CONFIG_FS_POSIX_ACL=y CONFIG_XFS_FS=y # CONFIG_XFS_QUOTA is not set CONFIG_XFS_SECURITY=y CONFIG_XFS_POSIX_ACL=y CONFIG_XFS_RT=y CONFIG_GFS2_FS=y CONFIG_GFS2_FS_LOCKING_NOLOCK=y CONFIG_GFS2_FS_LOCKING_DLM=y # CONFIG_OCFS2_FS is not set CONFIG_MINIX_FS=y CONFIG_ROMFS_FS=y # CONFIG_INOTIFY is not set # CONFIG_QUOTA is not set CONFIG_DNOTIFY=y CONFIG_AUTOFS_FS=y CONFIG_AUTOFS4_FS=y CONFIG_FUSE_FS=y CONFIG_GENERIC_ACL=y # # CD-ROM/DVD Filesystems # # CONFIG_ISO9660_FS is not set CONFIG_UDF_FS=y CONFIG_UDF_NLS=y # # DOS/FAT/NT Filesystems # CONFIG_FAT_FS=y CONFIG_MSDOS_FS=y CONFIG_VFAT_FS=y CONFIG_FAT_DEFAULT_CODEPAGE=437 CONFIG_FAT_DEFAULT_IOCHARSET="iso8859-1" # CONFIG_NTFS_FS is not set # # Pseudo filesystems # CONFIG_PROC_FS=y CONFIG_PROC_KCORE=y CONFIG_PROC_SYSCTL=y CONFIG_SYSFS=y CONFIG_TMPFS=y CONFIG_TMPFS_POSIX_ACL=y # CONFIG_HUGETLBFS is not set # CONFIG_HUGETLB_PAGE is not set CONFIG_CONFIGFS_FS=y # # Miscellaneous filesystems # CONFIG_ADFS_FS=y # CONFIG_ADFS_FS_RW is not set CONFIG_AFFS_FS=y CONFIG_ECRYPT_FS=y CONFIG_HFS_FS=y CONFIG_HFSPLUS_FS=y # CONFIG_BEFS_FS is not set CONFIG_BFS_FS=y # CONFIG_EFS_FS is not set # CONFIG_CRAMFS is not set # CONFIG_VXFS_FS is not set CONFIG_HPFS_FS=y # CONFIG_QNX4FS_FS is not set # CONFIG_SYSV_FS is not set CONFIG_UFS_FS=y CONFIG_UFS_FS_WRITE=y CONFIG_UFS_DEBUG=y CONFIG_NETWORK_FILESYSTEMS=y # CONFIG_NFS_FS is not set CONFIG_NFSD=y # CONFIG_NFSD_V3 is not set # CONFIG_NFSD_TCP is not set CONFIG_LOCKD=y CONFIG_EXPORTFS=y CONFIG_NFS_COMMON=y CONFIG_SUNRPC=y CONFIG_SUNRPC_GSS=y CONFIG_SUNRPC_XPRT_RDMA=y # CONFIG_SUNRPC_BIND34 is not set # CONFIG_RPCSEC_GSS_KRB5 is not set CONFIG_RPCSEC_GSS_SPKM3=y # CONFIG_SMB_FS is not set CONFIG_CIFS=y # CONFIG_CIFS_STATS is not set # CONFIG_CIFS_WEAK_PW_HASH is not set # CONFIG_CIFS_XATTR is not set # CONFIG_CIFS_DEBUG2 is not set CONFIG_CIFS_EXPERIMENTAL=y # CONFIG_CIFS_UPCALL is not set # CONFIG_NCP_FS is not set CONFIG_CODA_FS=y # CONFIG_CODA_FS_OLD_API is not set CONFIG_AFS_FS=y # CONFIG_AFS_DEBUG is not set # CONFIG_9P_FS is not set # # Partition Types # CONFIG_PARTITION_ADVANCED=y CONFIG_ACORN_PARTITION=y # CONFIG_ACORN_PARTITION_CUMANA is not set # CONFIG_ACORN_PARTITION_EESOX is not set CONFIG_ACORN_PARTITION_ICS=y # CONFIG_ACORN_PARTITION_ADFS is not set # CONFIG_ACORN_PARTITION_POWERTEC is not set CONFIG_ACORN_PARTITION_RISCIX=y CONFIG_OSF_PARTITION=y CONFIG_AMIGA_PARTITION=y CONFIG_ATARI_PARTITION=y CONFIG_MAC_PARTITION=y CONFIG_MSDOS_PARTITION=y CONFIG_BSD_DISKLABEL=y CONFIG_MINIX_SUBPARTITION=y # CONFIG_SOLARIS_X86_PARTITION is not set CONFIG_UNIXWARE_DISKLABEL=y # CONFIG_LDM_PARTITION is not set # CONFIG_SGI_PARTITION is not set CONFIG_ULTRIX_PARTITION=y # CONFIG_SUN_PARTITION is not set # CONFIG_KARMA_PARTITION is not set # CONFIG_EFI_PARTITION is not set # CONFIG_SYSV68_PARTITION is not set CONFIG_NLS=y CONFIG_NLS_DEFAULT="iso8859-1" # CONFIG_NLS_CODEPAGE_437 is not set CONFIG_NLS_CODEPAGE_737=y CONFIG_NLS_CODEPAGE_775=y CONFIG_NLS_CODEPAGE_850=y # CONFIG_NLS_CODEPAGE_852 is not set CONFIG_NLS_CODEPAGE_855=y CONFIG_NLS_CODEPAGE_857=y # CONFIG_NLS_CODEPAGE_860 is not set # CONFIG_NLS_CODEPAGE_861 is not set # CONFIG_NLS_CODEPAGE_862 is not set # CONFIG_NLS_CODEPAGE_863 is not set CONFIG_NLS_CODEPAGE_864=y # CONFIG_NLS_CODEPAGE_865 is not set # CONFIG_NLS_CODEPAGE_866 is not set # CONFIG_NLS_CODEPAGE_869 is not set # CONFIG_NLS_CODEPAGE_936 is not set # CONFIG_NLS_CODEPAGE_950 is not set CONFIG_NLS_CODEPAGE_932=y # CONFIG_NLS_CODEPAGE_949 is not set # CONFIG_NLS_CODEPAGE_874 is not set # CONFIG_NLS_ISO8859_8 is not set # CONFIG_NLS_CODEPAGE_1250 is not set # CONFIG_NLS_CODEPAGE_1251 is not set CONFIG_NLS_ASCII=y # CONFIG_NLS_ISO8859_1 is not set CONFIG_NLS_ISO8859_2=y CONFIG_NLS_ISO8859_3=y # CONFIG_NLS_ISO8859_4 is not set # CONFIG_NLS_ISO8859_5 is not set # CONFIG_NLS_ISO8859_6 is not set CONFIG_NLS_ISO8859_7=y CONFIG_NLS_ISO8859_9=y # CONFIG_NLS_ISO8859_13 is not set CONFIG_NLS_ISO8859_14=y CONFIG_NLS_ISO8859_15=y CONFIG_NLS_KOI8_R=y # CONFIG_NLS_KOI8_U is not set CONFIG_NLS_UTF8=y CONFIG_DLM=y # CONFIG_DLM_DEBUG is not set CONFIG_INSTRUMENTATION=y CONFIG_PROFILING=y CONFIG_OPROFILE=y CONFIG_MARKERS=y # # Kernel hacking # CONFIG_TRACE_IRQFLAGS_SUPPORT=y # CONFIG_PRINTK_TIME is not set CONFIG_ENABLE_WARN_DEPRECATED=y CONFIG_ENABLE_MUST_CHECK=y CONFIG_MAGIC_SYSRQ=y CONFIG_UNUSED_SYMBOLS=y CONFIG_DEBUG_FS=y CONFIG_HEADERS_CHECK=y CONFIG_DEBUG_KERNEL=y # CONFIG_DEBUG_SHIRQ is not set # CONFIG_DETECT_SOFTLOCKUP is not set CONFIG_SCHED_DEBUG=y CONFIG_SCHEDSTATS=y # CONFIG_TIMER_STATS is not set CONFIG_SLUB_DEBUG_ON=y # CONFIG_DEBUG_RT_MUTEXES is not set # CONFIG_RT_MUTEX_TESTER is not set CONFIG_DEBUG_SPINLOCK=y CONFIG_DEBUG_MUTEXES=y CONFIG_DEBUG_LOCK_ALLOC=y # CONFIG_PROVE_LOCKING is not set CONFIG_LOCKDEP=y # CONFIG_LOCK_STAT is not set # CONFIG_DEBUG_LOCKDEP is not set # CONFIG_DEBUG_SPINLOCK_SLEEP is not set CONFIG_DEBUG_LOCKING_API_SELFTESTS=y CONFIG_STACKTRACE=y # CONFIG_DEBUG_KOBJECT is not set CONFIG_DEBUG_BUGVERBOSE=y # CONFIG_DEBUG_INFO is not set # CONFIG_DEBUG_VM is not set # CONFIG_DEBUG_LIST is not set # CONFIG_DEBUG_SG is not set CONFIG_FRAME_POINTER=y # CONFIG_FORCED_INLINING is not set CONFIG_BOOT_PRINTK_DELAY=y # CONFIG_BACKTRACE_SELF_TEST is not set # CONFIG_FAULT_INJECTION is not set CONFIG_PROVIDE_OHCI1394_DMA_INIT=y # CONFIG_SAMPLES is not set # CONFIG_WANT_EXTRA_DEBUG_INFORMATION is not set # CONFIG_UNWIND_INFO is not set # CONFIG_KGDB is not set CONFIG_EARLY_PRINTK=y CONFIG_DEBUG_STACKOVERFLOW=y # CONFIG_DEBUG_STACK_USAGE is not set CONFIG_DEBUG_PAGEALLOC=y # CONFIG_DEBUG_RODATA is not set # CONFIG_4KSTACKS is not set CONFIG_X86_FIND_SMP_CONFIG=y CONFIG_X86_MPPARSE=y CONFIG_DOUBLEFAULT=y CONFIG_IO_DELAY_TYPE_0X80=0 CONFIG_IO_DELAY_TYPE_0XED=1 CONFIG_IO_DELAY_TYPE_UDELAY=2 CONFIG_IO_DELAY_TYPE_NONE=3 CONFIG_IO_DELAY_0X80=y # CONFIG_IO_DELAY_0XED is not set # CONFIG_IO_DELAY_UDELAY is not set # CONFIG_IO_DELAY_NONE is not set CONFIG_DEFAULT_IO_DELAY_TYPE=0 # CONFIG_DEBUG_BOOT_PARAMS is not set CONFIG_CPA_DEBUG=y # # Security options # CONFIG_KEYS=y CONFIG_KEYS_DEBUG_PROC_KEYS=y CONFIG_SECURITY=y # CONFIG_SECURITY_NETWORK is not set CONFIG_SECURITY_CAPABILITIES=y CONFIG_SECURITY_FILE_CAPABILITIES=y # CONFIG_SECURITY_ROOTPLUG is not set CONFIG_CRYPTO=y CONFIG_CRYPTO_ALGAPI=y CONFIG_CRYPTO_BLKCIPHER=y CONFIG_CRYPTO_HASH=y CONFIG_CRYPTO_MANAGER=y CONFIG_CRYPTO_HMAC=y CONFIG_CRYPTO_XCBC=y # CONFIG_CRYPTO_NULL is not set # CONFIG_CRYPTO_MD4 is not set CONFIG_CRYPTO_MD5=y CONFIG_CRYPTO_SHA1=y CONFIG_CRYPTO_SHA256=y CONFIG_CRYPTO_SHA512=y CONFIG_CRYPTO_WP512=y # CONFIG_CRYPTO_TGR192 is not set CONFIG_CRYPTO_GF128MUL=y CONFIG_CRYPTO_ECB=y CONFIG_CRYPTO_CBC=y CONFIG_CRYPTO_PCBC=y # CONFIG_CRYPTO_LRW is not set CONFIG_CRYPTO_XTS=y # CONFIG_CRYPTO_CRYPTD is not set CONFIG_CRYPTO_DES=y CONFIG_CRYPTO_FCRYPT=y # CONFIG_CRYPTO_BLOWFISH is not set # CONFIG_CRYPTO_TWOFISH is not set # CONFIG_CRYPTO_TWOFISH_586 is not set # CONFIG_CRYPTO_SERPENT is not set CONFIG_CRYPTO_AES=y CONFIG_CRYPTO_AES_586=y CONFIG_CRYPTO_CAST5=y # CONFIG_CRYPTO_CAST6 is not set # CONFIG_CRYPTO_TEA is not set CONFIG_CRYPTO_ARC4=y # CONFIG_CRYPTO_KHAZAD is not set CONFIG_CRYPTO_ANUBIS=y # CONFIG_CRYPTO_SEED is not set CONFIG_CRYPTO_DEFLATE=y # CONFIG_CRYPTO_MICHAEL_MIC is not set CONFIG_CRYPTO_CRC32C=y # CONFIG_CRYPTO_CAMELLIA is not set # CONFIG_CRYPTO_AUTHENC is not set CONFIG_CRYPTO_HW=y CONFIG_CRYPTO_DEV_PADLOCK=y # CONFIG_CRYPTO_DEV_PADLOCK_AES is not set CONFIG_CRYPTO_DEV_PADLOCK_SHA=y # CONFIG_CRYPTO_DEV_GEODE is not set # # Library routines # CONFIG_BITREVERSE=y CONFIG_CRC_CCITT=y # CONFIG_CRC16 is not set CONFIG_CRC_ITU_T=y CONFIG_CRC32=y # CONFIG_CRC7 is not set CONFIG_LIBCRC32C=y CONFIG_ZLIB_INFLATE=y CONFIG_ZLIB_DEFLATE=y CONFIG_TEXTSEARCH=y CONFIG_TEXTSEARCH_KMP=y CONFIG_TEXTSEARCH_BM=y CONFIG_TEXTSEARCH_FSM=y CONFIG_PLIST=y CONFIG_HAS_IOMEM=y CONFIG_HAS_IOPORT=y CONFIG_HAS_DMA=y CONFIG_CHECK_SIGNATURE=y [-- Attachment #3: crash.log --] [-- Type: text/plain, Size: 9968 bytes --] Linux version 2.6.24-rc8 (mingo@dione) (gcc version 4.2.2) #15 SMP Tue Jan 22 17:43:21 CET 2008 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009f800 (usable) BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000003fff0000 (usable) BIOS-e820: 000000003fff0000 - 000000003fff3000 (ACPI NVS) BIOS-e820: 000000003fff3000 - 0000000040000000 (ACPI data) BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) BIOS-e820: 00000000fec00000 - 0000000100000000 (reserved) console [earlyser0] enabled Warning only 896MB will be used. Use a HIGHMEM enabled kernel. 896MB LOWMEM available. Scan SMP from c0000000 for 1024 bytes. Scan SMP from c009fc00 for 1024 bytes. Scan SMP from c00f0000 for 65536 bytes. found SMP MP-table at [c00f5680] 000f5680 Entering add_active_range(0, 0, 229376) 0 entries of 256 used Zone PFN ranges: DMA 0 -> 4096 Normal 4096 -> 229376 Movable zone start PFN for each node early_node_map[1] active PFN ranges 0: 0 -> 229376 On node 0 totalpages: 229376 DMA zone: 52 pages used for memmap DMA zone: 0 pages reserved DMA zone: 4044 pages, LIFO batch:0 Normal zone: 2860 pages used for memmap Normal zone: 222420 pages, LIFO batch:31 Movable zone: 0 pages used for memmap DMI 2.3 present. ACPI: RSDP 000F76F0, 0014 (r0 Nvidia) ACPI: RSDT 3FFF3040, 0034 (r1 Nvidia AWRDACPI 42302E31 AWRD 0) ACPI: FACP 3FFF30C0, 0074 (r1 Nvidia AWRDACPI 42302E31 AWRD 0) ACPI: DSDT 3FFF3180, 6264 (r1 NVIDIA AWRDACPI 1000 MSFT 100000E) ACPI: FACS 3FFF0000, 0040 ACPI: SRAT 3FFF9500, 00A0 (r1 AMD HAMMER 1 AMD 1) ACPI: MCFG 3FFF9600, 003C (r1 Nvidia AWRDACPI 42302E31 AWRD 0) ACPI: APIC 3FFF9440, 007C (r1 Nvidia AWRDACPI 42302E31 AWRD 0) Nvidia board detected. Ignoring ACPI timer override. If you got timer trouble try acpi_use_timer_override ACPI: PM-Timer IO Port: 0x4008 Intel MultiProcessor Specification v1.4 Virtual Wire compatibility mode. OEM ID: OEM00000 Product ID: PROD00000000 APIC at: 0xFEE00000 Processor #0 15:3 APIC version 17 Processor #1 15:3 APIC version 17 I/O APIC #2 Version 17 at 0xFEC00000. Enabling APIC mode: Flat. Using 1 I/O APICs Processors: 2 Allocating PCI resources starting at 50000000 (gap: 40000000:a0000000) Built 1 zonelists in Zone order, mobility grouping on. Total pages: 226464 Kernel command line: root=/dev/sda1 console=ttyS0,115200 console=tty earlyprintk=serial,ttyS0,115200 3 profile=0 debug initcall_debug enforcing=0 apic=verbose sysrq_always_enabled ignore_loglevel selinux=0 nosmp highres=0 nolapic idle=mwait nopat kernel profiling enabled (shift: 0) debug: sysrq always enabled. debug: ignoring loglevel setting. mapped APIC to ffffb000 (fee00000) mapped IOAPIC to ffffa000 (fec00000) Enabling fast FPU save and restore... done. Enabling unmasked SIMD FPU exception support... done. Initializing CPU#0 PID hash table entries: 4096 (order: 12, 16384 bytes) Detected 2160.224 MHz processor. spurious 8259A interrupt: IRQ7. Console: colour VGA+ 80x25 console handover: boot [earlyser0] -> real [tty0] console [ttyS0] enabled Lock dependency validator: Copyright (c) 2006 Red Hat, Inc., Ingo Molnar ... MAX_LOCKDEP_SUBCLASSES: 8 ... MAX_LOCK_DEPTH: 30 ... MAX_LOCKDEP_KEYS: 2048 ... CLASSHASH_SIZE: 1024 ... MAX_LOCKDEP_ENTRIES: 8192 ... MAX_LOCKDEP_CHAINS: 16384 ... CHAINHASH_SIZE: 8192 memory used by lock dependency info: 992 kB per task-struct memory footprint: 1200 bytes ------------------------ | Locking API testsuite: ---------------------------------------------------------------------------- | spin |wlock |rlock |mutex | wsem | rsem | -------------------------------------------------------------------------- A-A deadlock:failed|failed| ok |failed|failed|failed| A-B-B-A deadlock:failed|failed| ok |failed|failed|failed| A-B-B-C-C-A deadlock:failed|failed| ok |failed|failed|failed| A-B-C-A-B-C deadlock:failed|failed| ok |failed|failed|failed| A-B-B-C-C-D-D-A deadlock:failed|failed| ok |failed|failed|failed| A-B-C-D-B-D-D-A deadlock:failed|failed| ok |failed|failed|failed| A-B-C-D-B-C-D-A deadlock:failed|failed| ok |failed|failed|failed| double unlock: ok | ok |failed| ok |failed|failed| initialize held:failed|failed|failed|failed|failed|failed| bad unlock order: ok | ok | ok | ok | ok | ok | -------------------------------------------------------------------------- recursive read-lock: | ok | |failed| recursive read-lock #2: | ok | |failed| mixed read-write-lock: |failed| |failed| mixed write-read-lock: |failed| |failed| -------------------------------------------------------------------------- hard-irqs-on + irq-safe-A/12:failed|failed| ok | soft-irqs-on + irq-safe-A/12:failed|failed| ok | hard-irqs-on + irq-safe-A/21:failed|failed| ok | soft-irqs-on + irq-safe-A/21:failed|failed| ok | sirq-safe-A => hirqs-on/12:failed|failed| ok | sirq-safe-A => hirqs-on/21:failed|failed| ok | hard-safe-A + irqs-on/12:failed|failed| ok | soft-safe-A + irqs-on/12:failed|failed| ok | hard-safe-A + irqs-on/21:failed|failed| ok | soft-safe-A + irqs-on/21:failed|failed| ok | hard-safe-A + unsafe-B #1/123:failed|failed| ok | soft-safe-A + unsafe-B #1/123:failed|failed| ok | hard-safe-A + unsafe-B #1/132:failed|failed| ok | soft-safe-A + unsafe-B #1/132:failed|failed| ok | hard-safe-A + unsafe-B #1/213:failed|failed| ok | soft-safe-A + unsafe-B #1/213:failed|failed| ok | hard-safe-A + unsafe-B #1/231:failed|failed| ok | soft-safe-A + unsafe-B #1/231:failed|failed| ok | hard-safe-A + unsafe-B #1/312:failed|failed| ok | soft-safe-A + unsafe-B #1/312:failed|failed| ok | hard-safe-A + unsafe-B #1/321:failed|failed| ok | soft-safe-A + unsafe-B #1/321:failed|failed| ok | hard-safe-A + unsafe-B #2/123:failed|failed| ok | soft-safe-A + unsafe-B #2/123:failed|failed| ok | hard-safe-A + unsafe-B #2/132:failed|failed| ok | soft-safe-A + unsafe-B #2/132:failed|failed| ok | hard-safe-A + unsafe-B #2/213:failed|failed| ok | soft-safe-A + unsafe-B #2/213:failed|failed| ok | hard-safe-A + unsafe-B #2/231:failed|failed| ok | soft-safe-A + unsafe-B #2/231:failed|failed| ok | hard-safe-A + unsafe-B #2/312:failed|failed| ok | soft-safe-A + unsafe-B #2/312:failed|failed| ok | hard-safe-A + unsafe-B #2/321:failed|failed| ok | soft-safe-A + unsafe-B #2/321:failed|failed| ok | hard-irq lock-inversion/123:failed|failed| ok | soft-irq lock-inversion/123:failed|failed| ok | hard-irq lock-inversion/132:failed|failed| ok | soft-irq lock-inversion/132:failed|failed| ok | hard-irq lock-inversion/213:failed|failed| ok | soft-irq lock-inversion/213:failed|failed| ok | hard-irq lock-inversion/231:failed|failed| ok | soft-irq lock-inversion/231:failed|failed| ok | hard-irq lock-inversion/312:failed|failed| ok | soft-irq lock-inversion/312:failed|failed| ok | hard-irq lock-inversion/321:failed|failed| ok | soft-irq lock-inversion/321:failed|failed| ok | hard-irq read-recursion/123: ok | soft-irq read-recursion/123: ok | hard-irq read-recursion/132: ok | soft-irq read-recursion/132: ok | hard-irq read-recursion/213: ok | soft-irq read-recursion/213: ok | hard-irq read-recursion/231: ok | soft-irq read-recursion/231: ok | hard-irq read-recursion/312: ok | soft-irq read-recursion/312: ok | hard-irq read-recursion/321: ok | soft-irq read-recursion/321: ok | -------------------------------------------------------- 142 out of 218 testcases failed, as expected. | ---------------------------------------------------- Dentry cache hash table entries: 131072 (order: 7, 524288 bytes) Inode-cache hash table entries: 65536 (order: 6, 262144 bytes) ------------[ cut here ]------------ kernel BUG at arch/x86/mm/pageattr_32.c:327! invalid opcode: 0000 [#1] SMP DEBUG_PAGEALLOC Pid: 0, comm: swapper Not tainted (2.6.24-rc8 #15) EIP: 0060:[<c0116a3f>] EFLAGS: 00010297 CPU: 0 EIP is at kernel_map_pages+0x52/0xb3 EAX: c0a6fc00 EBX: c0003000 ECX: c0a6fc00 EDX: c0a6fc00 ESI: c100109c EDI: 00000000 EBP: c0a19f34 ESP: c0a19f1c DS: 007b ES: 007b FS: 00d8 GS: 0000 SS: 0068 Process swapper (pid: 0, ti=c0a18000 task=c0902390 task.ti=c0a18000) Stack: 00000000 00000001 00000002 c100109c 00000000 ffffffff c0a19f50 c014a77e 00000000 c090ba10 c100109c 00000000 00000003 c0a19f58 c014a844 c0a19f60 c014adea c0a19f70 c0a2f8b6 fffffff8 c100109c c0a19fa4 c0a2e2f5 00000005 Call Trace: [<c014a77e>] ? free_hot_cold_page+0xb5/0x13c [<c014a844>] ? free_hot_page+0xa/0xc [<c014adea>] ? __free_pages+0x1b/0x26 [<c0a2f8b6>] ? __free_pages_bootmem+0x54/0x58 [<c0a2e2f5>] ? free_all_bootmem_core+0xde/0x154 [<c0a2e378>] ? free_all_bootmem+0xd/0xf [<c0a2b2d1>] ? mem_init+0x26/0x21e [<c0a21862>] ? start_kernel+0x273/0x2f9 ======================= Code: 00 c0 85 c9 74 04 31 ff eb 73 8b 55 ec c1 e2 0c 89 d8 e8 67 51 02 00 eb ed 8d 55 f0 89 d8 e8 e9 fa ff ff 89 c2 83 7d f0 03 74 04 <0f> 0b eb fe 83 7d e8 00 74 24 89 f0 2b 05 24 11 c4 c0 c1 f8 02 EIP: [<c0116a3f>] kernel_map_pages+0x52/0xb3 SS:ESP 0068:c0a19f1c ---[ end trace ca143223eefdc828 ]--- Kernel panic - not syncing: Attempted to kill the idle task! ^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH] x86_32: trim memory by updating e820 v3 2008-01-22 16:51 ` Ingo Molnar @ 2008-01-23 0:23 ` Yinghai Lu 2008-04-26 10:56 ` Andrew Morton 0 siblings, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-01-23 0:23 UTC (permalink / raw) To: Ingo Molnar; +Cc: Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, Andrew Morton [PATCH] x86_32: trim memory by updating e820 v3 when mtrr is not covering all e820 table, need to trim the ram, need to update e820 reuse some code for x86_64 here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early need Justine to test with his special system with bug bios. Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> Index: linux-2.6/arch/x86/kernel/cpu/common.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/common.c +++ linux-2.6/arch/x86/kernel/cpu/common.c @@ -278,6 +278,33 @@ void __init cpu_detect(struct cpuinfo_x8 c->x86_cache_alignment = ((misc >> 8) & 0xff) * 8; } } +static void __cpuinit early_get_cap(struct cpuinfo_x86 *c) +{ + u32 tfms, xlvl; + int ebx; + + memset(&c->x86_capability, 0, sizeof c->x86_capability); + if (have_cpuid_p()) { + /* Intel-defined flags: level 0x00000001 */ + if (c->cpuid_level >= 0x00000001) { + u32 capability, excap; + cpuid(0x00000001, &tfms, &ebx, &excap, &capability); + c->x86_capability[0] = capability; + c->x86_capability[4] = excap; + } + + /* AMD-defined flags: level 0x80000001 */ + xlvl = cpuid_eax(0x80000000); + if ((xlvl & 0xffff0000) == 0x80000000) { + if (xlvl >= 0x80000001) { + c->x86_capability[1] = cpuid_edx(0x80000001); + c->x86_capability[6] = cpuid_ecx(0x80000001); + } + } + + } + +} /* Do minimum CPU detection early. Fields really needed: vendor, cpuid_level, family, model, mask, cache alignment. @@ -306,6 +333,8 @@ static void __init early_cpu_detect(void early_init_intel(c); break; } + + early_get_cap(c); } static void __cpuinit generic_identify(struct cpuinfo_x86 * c) @@ -485,7 +514,6 @@ void __init identify_boot_cpu(void) identify_cpu(&boot_cpu_data); sysenter_setup(); enable_sep_cpu(); - mtrr_bp_init(); } void __cpuinit identify_secondary_cpu(struct cpuinfo_x86 *c) Index: linux-2.6/arch/x86/kernel/setup_32.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/setup_32.c +++ linux-2.6/arch/x86/kernel/setup_32.c @@ -49,6 +49,7 @@ #include <video/edid.h> +#include <asm/mtrr.h> #include <asm/apic.h> #include <asm/e820.h> #include <asm/mpspec.h> @@ -762,6 +763,11 @@ void __init setup_arch(char **cmdline_p) max_low_pfn = setup_memory(); + /* update e820 for memory not covered by WB MTRRs */ + mtrr_bp_init(); + if (mtrr_trim_uncached_memory(max_pfn)) + max_low_pfn = setup_memory(); + #ifdef CONFIG_VMI /* * Must be after max_low_pfn is determined, and before kernel Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c +++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c @@ -624,7 +624,6 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; -#ifdef CONFIG_X86_64 static int disable_mtrr_trim; static int __init disable_mtrr_trim_setup(char *str) @@ -726,7 +725,6 @@ int __init mtrr_trim_uncached_memory(uns return 0; } -#endif /** * mtrr_bp_init - initialize mtrrs on the boot CPU Index: linux-2.6/Documentation/kernel-parameters.txt =================================================================== --- linux-2.6.orig/Documentation/kernel-parameters.txt +++ linux-2.6/Documentation/kernel-parameters.txt @@ -575,7 +575,7 @@ and is between 256 and 4096 characters. See drivers/char/README.epca and Documentation/digiepca.txt. - disable_mtrr_trim [X86-64, Intel only] + disable_mtrr_trim [X86, Intel and AMD only] By default the kernel will trim any uncacheable memory out of your available memory pool based on MTRR settings. This parameter disables that behavior, Index: linux-2.6/arch/x86/kernel/e820_32.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/e820_32.c +++ linux-2.6/arch/x86/kernel/e820_32.c @@ -749,3 +749,14 @@ static int __init parse_memmap(char *arg return 0; } early_param("memmap", parse_memmap); +void __init update_e820(void) +{ + u8 nr_map; + + nr_map = e820.nr_map; + if (sanitize_e820_map(e820.map, &nr_map)) + return; + e820.nr_map = nr_map; + printk(KERN_INFO "modified physical RAM map:\n"); + print_memory_map("modified"); +} Index: linux-2.6/include/asm-x86/e820_32.h =================================================================== --- linux-2.6.orig/include/asm-x86/e820_32.h +++ linux-2.6/include/asm-x86/e820_32.h @@ -19,12 +19,15 @@ #ifndef __ASSEMBLY__ extern struct e820map e820; +extern void update_e820(void); extern int e820_all_mapped(unsigned long start, unsigned long end, unsigned type); extern int e820_any_mapped(u64 start, u64 end, unsigned type); extern void find_max_pfn(void); extern void register_bootmem_low_pages(unsigned long max_low_pfn); +extern void add_memory_region(unsigned long long start, + unsigned long long size, int type); extern void e820_register_memory(void); extern void limit_regions(unsigned long long size); extern void print_memory_map(char *who); ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-01-23 0:23 ` [PATCH] x86_32: trim memory by updating e820 v3 Yinghai Lu @ 2008-04-26 10:56 ` Andrew Morton 2008-04-26 12:56 ` Gabriel C ` (3 more replies) 0 siblings, 4 replies; 87+ messages in thread From: Andrew Morton @ 2008-04-26 10:56 UTC (permalink / raw) To: Yinghai Lu Cc: Ingo Molnar, Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: > [PATCH] x86_32: trim memory by updating e820 v3 > > when mtrr is not covering all e820 table, need to trim the ram, need to update e820 > > reuse some code for x86_64 > > here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early > > need Justine to test with his special system with bug bios. > > Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> Speaking of mtrr and e820.... Could someone please take a peek at http://bugzilla.kernel.org/show_bug.cgi?id=10508 ? For some reason we seem to have turned this: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) into this: reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 which screws up the X server's attempt to map the video memory at 0xd0000000. Thanks. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-26 10:56 ` Andrew Morton @ 2008-04-26 12:56 ` Gabriel C 2008-04-27 1:05 ` Yinghai Lu 2008-04-28 6:44 ` Yinghai Lu 2008-04-27 0:57 ` [PATCH] x86_32: trim memory by updating e820 v3 Yinghai Lu ` (2 subsequent siblings) 3 siblings, 2 replies; 87+ messages in thread From: Gabriel C @ 2008-04-26 12:56 UTC (permalink / raw) To: Andrew Morton Cc: Yinghai Lu, Ingo Molnar, Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao Andrew Morton wrote: > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: > >> [PATCH] x86_32: trim memory by updating e820 v3 >> >> when mtrr is not covering all e820 table, need to trim the ram, need to update e820 >> >> reuse some code for x86_64 >> >> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early >> >> need Justine to test with his special system with bug bios. >> >> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> > > Speaking of mtrr and e820.... > > Could someone please take a peek at > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ? > > For some reason we seem to have turned this: > > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) > [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) > [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) > [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) > [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) > [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) > [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) > [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) > [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) > [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) > [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) > > into this: > > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > > which screws up the X server's attempt to map the video memory at > 0xd0000000. I see that on my box with ASUS P5E-VM DO and 4G RAM. It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS. I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit. Also I get the mtrr type mismatch message on 32 and 64 bit kernels. ... [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) ... cat /proc/mtrr : reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 dmesg is saying : .. [ 24.012694] [drm] Initialized i915 1.6.0 20060119 on minor 0 [ 24.175500] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining [ 24.423740] set status page addr 0x00033000 .. from Xorg log : ... (WW) intel(0): Failed to set up write-combining range (0xd0000000,0x10000000) (II) intel(0): vgaHWGetIOBase: hwp->IOBase is 0x03d0, hwp->PIOOffset is 0x0000 ... Regards, Gabriel ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-26 12:56 ` Gabriel C @ 2008-04-27 1:05 ` Yinghai Lu 2008-04-28 18:07 ` Eric W. Biederman 2008-04-28 6:44 ` Yinghai Lu 1 sibling, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-27 1:05 UTC (permalink / raw) To: Gabriel C, Eric W. Biederman, Andi Kleen Cc: Andrew Morton, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote: > > Andrew Morton wrote: > > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: > > > >> [PATCH] x86_32: trim memory by updating e820 v3 > >> > >> when mtrr is not covering all e820 table, need to trim the ram, need to update e820 > >> > >> reuse some code for x86_64 > >> > >> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early > >> > >> need Justine to test with his special system with bug bios. > >> > >> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> > > > > Speaking of mtrr and e820.... > > > > Could someone please take a peek at > > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ? > > > > For some reason we seem to have turned this: > > > > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) > > [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) > > [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) > > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) > > [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) > > [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) > > [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) > > [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) > > [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) > > [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) > > [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) > > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > > [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) > > [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) > > > > into this: > > > > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 > > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 > > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > > > > which screws up the X server's attempt to map the video memory at > > 0xd0000000. > > I see that on my box with ASUS P5E-VM DO and 4G RAM. > It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS. > > I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit. > > Also I get the mtrr type mismatch message on 32 and 64 bit kernels. > > ... > > [ 0.000000] BIOS-provided physical RAM map: > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) > [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) > [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) > [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) > [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) > [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) > > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) > [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) > ... > > cat /proc/mtrr : > > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 > reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 > reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 > > > dmesg is saying : > > .. > > [ 24.012694] [drm] Initialized i915 1.6.0 20060119 on minor 0 > [ 24.175500] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining > [ 24.423740] set status page addr 0x00033000 another continuous MTRR mapping. several months ago, we were talking about modifying MTRR. but Eric said that is not safe because acpi and smi... YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-27 1:05 ` Yinghai Lu @ 2008-04-28 18:07 ` Eric W. Biederman 2008-04-28 23:16 ` Yinghai Lu 2008-04-29 10:31 ` Ingo Molnar 0 siblings, 2 replies; 87+ messages in thread From: Eric W. Biederman @ 2008-04-28 18:07 UTC (permalink / raw) To: Yinghai Lu Cc: Gabriel C, Andi Kleen, Andrew Morton, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao "Yinghai Lu" <yhlu.kernel@gmail.com> writes: > On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote: > another continuous MTRR mapping. > > several months ago, we were talking about modifying MTRR. but Eric > said that is not safe because acpi and smi... I think it was Andi who spotted that originally, and yes I do think it is a pretty horrific failure mode. Reprogramming the MTRRs requires full knowledge of the hardware and what is going on that we don't always have. PAT support has just been merged, and using that only requires knowledge about the region whose attributes we intend to change. So lets concentrate on PAT to solve contiguous MTRR region problems. We can upgrade UC to WC with pat. As well as demote WB to UC or WC. So for those regions we know about we should be in good shape. In a slightly related vein. Trimming the memory we consider usable by looking at MTRRs and if a region is not WB not considering it RAM sounds like a very reasonable work around for one class of BIOS bugs. Eric ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 18:07 ` Eric W. Biederman @ 2008-04-28 23:16 ` Yinghai Lu 2008-04-29 10:31 ` Ingo Molnar 1 sibling, 0 replies; 87+ messages in thread From: Yinghai Lu @ 2008-04-28 23:16 UTC (permalink / raw) To: Eric W. Biederman Cc: Gabriel C, Andi Kleen, Andrew Morton, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao On Mon, Apr 28, 2008 at 11:07 AM, Eric W. Biederman <ebiederm@xmission.com> wrote: > "Yinghai Lu" <yhlu.kernel@gmail.com> writes: > > > On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote: > > > > another continuous MTRR mapping. > > > > several months ago, we were talking about modifying MTRR. but Eric > > said that is not safe because acpi and smi... > > I think it was Andi who spotted that originally, and yes I do think it > is a pretty horrific failure mode. Reprogramming the MTRRs requires > full knowledge of the hardware and what is going on that we don't > always have. PAT support has just been merged, and using that only > requires knowledge about the region whose attributes we intend to change. > > So lets concentrate on PAT to solve contiguous MTRR region problems. > > We can upgrade UC to WC with pat. As well as demote WB to UC or WC. > So for those regions we know about we should be in good shape. > > In a slightly related vein. Trimming the memory we consider usable by > looking at MTRRs and if a region is not WB not considering it RAM > sounds like a very reasonable work around for one class of BIOS bugs. yeah, i will look at to loop the ram region array instead of checking highest_pfn only... YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 18:07 ` Eric W. Biederman 2008-04-28 23:16 ` Yinghai Lu @ 2008-04-29 10:31 ` Ingo Molnar 2008-04-29 17:29 ` Eric W. Biederman 1 sibling, 1 reply; 87+ messages in thread From: Ingo Molnar @ 2008-04-29 10:31 UTC (permalink / raw) To: Eric W. Biederman Cc: Yinghai Lu, Gabriel C, Andi Kleen, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao * Eric W. Biederman <ebiederm@xmission.com> wrote: > So lets concentrate on PAT to solve contiguous MTRR region problems. > > We can upgrade UC to WC with pat. As well as demote WB to UC or WC. > So for those regions we know about we should be in good shape. sure, but whatever we do now in the sysfs API space, it will hit distros only in a year, relistically, because Xorg also has to adopt to it. The workaround from Yinghai looks reasonably configurable - if we mess up (say an SMM comes in while we fiddle with the MTRRs) we'll likely get a lockup right then, during bootup, so it wont be hard to realize what went wrong. In that sense it's in fact safer to do it during early init than let the user do it via some script, because the window is smaller, etc. we still default to the safe mode of course and dont touch MTRRs, but for note the various configuration options that are available to distros and users. Ingo ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-29 10:31 ` Ingo Molnar @ 2008-04-29 17:29 ` Eric W. Biederman 2008-04-29 18:40 ` Yinghai Lu 0 siblings, 1 reply; 87+ messages in thread From: Eric W. Biederman @ 2008-04-29 17:29 UTC (permalink / raw) To: Ingo Molnar Cc: Yinghai Lu, Gabriel C, Andi Kleen, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao Ingo Molnar <mingo@elte.hu> writes: > * Eric W. Biederman <ebiederm@xmission.com> wrote: > >> So lets concentrate on PAT to solve contiguous MTRR region problems. >> >> We can upgrade UC to WC with pat. As well as demote WB to UC or WC. >> So for those regions we know about we should be in good shape. > > sure, but whatever we do now in the sysfs API space, it will hit distros > only in a year, relistically, because Xorg also has to adopt to it. The > workaround from Yinghai looks reasonably configurable - if we mess up > (say an SMM comes in while we fiddle with the MTRRs) we'll likely get a > lockup right then, during bootup, so it wont be hard to realize what > went wrong. In that sense it's in fact safer to do it during early init > than let the user do it via some script, because the window is smaller, > etc. > > we still default to the safe mode of course and dont touch MTRRs, but > for note the various configuration options that are available to distros > and users. The potential problem isn't while we reprogram the MTRRs, the potential problem is mapping the SMM area uncachable. In which case we will make each SMM interrupt drastically slower. Which can have all kinds of unpleasant side effects. If we really can mess up SMM mode that way we have a really nasty interaction that is horrible to debug, or recognize. Further the opportunity for this kind of fixup is small. Newer AMD systems don't need it as they have an extra way of specifying memory about 4G as WB. Systems with just the MTRRs can only use this when they have right around 4GB because with more memory there are not enough MTRRs to leave them non-overlapping and still mark all of memory WB. Eric ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-29 17:29 ` Eric W. Biederman @ 2008-04-29 18:40 ` Yinghai Lu 2008-04-29 19:19 ` Eric W. Biederman 0 siblings, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-29 18:40 UTC (permalink / raw) To: Eric W. Biederman Cc: Ingo Molnar, Gabriel C, Andi Kleen, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao On Tue, Apr 29, 2008 at 10:29 AM, Eric W. Biederman <ebiederm@xmission.com> wrote: > > Ingo Molnar <mingo@elte.hu> writes: > > > * Eric W. Biederman <ebiederm@xmission.com> wrote: > > > >> So lets concentrate on PAT to solve contiguous MTRR region problems. > >> > >> We can upgrade UC to WC with pat. As well as demote WB to UC or WC. > >> So for those regions we know about we should be in good shape. > > > > sure, but whatever we do now in the sysfs API space, it will hit distros > > only in a year, relistically, because Xorg also has to adopt to it. The > > workaround from Yinghai looks reasonably configurable - if we mess up > > (say an SMM comes in while we fiddle with the MTRRs) we'll likely get a > > lockup right then, during bootup, so it wont be hard to realize what > > went wrong. In that sense it's in fact safer to do it during early init > > than let the user do it via some script, because the window is smaller, > > etc. > > > > we still default to the safe mode of course and dont touch MTRRs, but > > for note the various configuration options that are available to distros > > and users. > > The potential problem isn't while we reprogram the MTRRs, the potential > problem is mapping the SMM area uncachable. In which case we will > make each SMM interrupt drastically slower. Which can have all kinds of > unpleasant side effects. and ACPI area too. that only try to make the continuous to discrete layout. and still try to cover all that is (WBs - UC) directly with WB. only thing is that could run out of MTRR..., and mtrr_gran_size is used to avoid that. then some RAM that is less than mtrr_gran_size could be dumped. so mtrr_gran_size could do sth. anyway this patch only can meet one end. for example Mika Fischer's system doesn't need to trim any RAM in MTRR. but for Gabriel's system may need to trim some RAM in MTRR. current mtrr_gran_size is default to 64M... may need another patch to loop all mtrr_chunk_size (2g, 1g, ...64M) , mtrr_gran_size (2g, 1g, ...1M) meet 1. leave one or two entry for X server driver 2. lose less cover for RAM in MTRR. anyway that should be done in BIOS. but ... > > If we really can mess up SMM mode that way we have a really nasty > interaction that is horrible to debug, or recognize. > > Further the opportunity for this kind of fixup is small. > Newer AMD systems don't need it as they have an extra > way of specifying memory about 4G as WB. Systems with just > the MTRRs can only use this when they have right around 4GB > because with more memory there are not enough MTRRs to leave them > non-overlapping and still mark all of memory WB. yes. the patch handle the AMD rev f later with mtrr_tom2. I have one system that give me - ( strange one ?) 0 - 128g WB 4g-512m, 4g wc after the patch i got 0 - 2048m wb 2048m - 1024m wb 3072m - 3584m wb YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-29 18:40 ` Yinghai Lu @ 2008-04-29 19:19 ` Eric W. Biederman 2008-04-29 19:44 ` Yinghai Lu 0 siblings, 1 reply; 87+ messages in thread From: Eric W. Biederman @ 2008-04-29 19:19 UTC (permalink / raw) To: Yinghai Lu Cc: Ingo Molnar, Gabriel C, Andi Kleen, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao "Yinghai Lu" <yhlu.kernel@gmail.com> writes: >> The potential problem isn't while we reprogram the MTRRs, the potential >> problem is mapping the SMM area uncachable. In which case we will >> make each SMM interrupt drastically slower. Which can have all kinds of >> unpleasant side effects. > > and ACPI area too. True but at least that one is visible. > that only try to make the continuous to discrete layout. and still try > to cover all that is (WBs - UC) directly with WB. > only thing is that could run out of MTRR..., and mtrr_gran_size is > used to avoid that. > then some RAM that is less than mtrr_gran_size could be dumped. > so mtrr_gran_size could do sth. > anyway this patch only can meet one end. > for example Mika Fischer's system doesn't need to trim any RAM in MTRR. > but for Gabriel's system may need to trim some RAM in MTRR. Right. Ram trimming (changing memory from WB to UC) is the potential problem. See my other post, in short I think we can address safely address all of the systems where the only problem is the selection of MTRRs by the BIOS. Then have an option (mtrr_chunk_size) for RAM trimming that is off by default. It is good to hear that some users and some systems get the benefit without trimming. Eric ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-29 19:19 ` Eric W. Biederman @ 2008-04-29 19:44 ` Yinghai Lu 2008-04-29 20:02 ` Eric W. Biederman 0 siblings, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-29 19:44 UTC (permalink / raw) To: Eric W. Biederman Cc: Ingo Molnar, Gabriel C, Andi Kleen, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao On Tue, Apr 29, 2008 at 12:19 PM, Eric W. Biederman <ebiederm@xmission.com> wrote: > "Yinghai Lu" <yhlu.kernel@gmail.com> writes: > > > >> The potential problem isn't while we reprogram the MTRRs, the potential > >> problem is mapping the SMM area uncachable. In which case we will > >> make each SMM interrupt drastically slower. Which can have all kinds of > >> unpleasant side effects. > > > > and ACPI area too. > > True but at least that one is visible. > > > > that only try to make the continuous to discrete layout. and still try > > to cover all that is (WBs - UC) directly with WB. > > only thing is that could run out of MTRR..., and mtrr_gran_size is > > used to avoid that. > > then some RAM that is less than mtrr_gran_size could be dumped. > > so mtrr_gran_size could do sth. > > anyway this patch only can meet one end. > > for example Mika Fischer's system doesn't need to trim any RAM in MTRR. > > but for Gabriel's system may need to trim some RAM in MTRR. > > Right. Ram trimming (changing memory from WB to UC) is the potential > problem. > > See my other post, in short I think we can address safely address all > of the systems where the only problem is the selection of MTRRs by the > BIOS. BIOS should provide the selection... > > Then have an option (mtrr_chunk_size) for RAM trimming that is > off by default. Yes. there is CONFIG option and boot command line to enable it. YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-29 19:44 ` Yinghai Lu @ 2008-04-29 20:02 ` Eric W. Biederman 0 siblings, 0 replies; 87+ messages in thread From: Eric W. Biederman @ 2008-04-29 20:02 UTC (permalink / raw) To: Yinghai Lu Cc: Ingo Molnar, Gabriel C, Andi Kleen, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao "Yinghai Lu" <yhlu.kernel@gmail.com> writes: > On Tue, Apr 29, 2008 at 12:19 PM, Eric W. Biederman > <ebiederm@xmission.com> wrote: >> "Yinghai Lu" <yhlu.kernel@gmail.com> writes: >> >> >> >> The potential problem isn't while we reprogram the MTRRs, the potential >> >> problem is mapping the SMM area uncachable. In which case we will >> >> make each SMM interrupt drastically slower. Which can have all kinds of >> >> unpleasant side effects. >> > >> > and ACPI area too. >> >> True but at least that one is visible. >> >> >> > that only try to make the continuous to discrete layout. and still try >> > to cover all that is (WBs - UC) directly with WB. >> > only thing is that could run out of MTRR..., and mtrr_gran_size is >> > used to avoid that. >> > then some RAM that is less than mtrr_gran_size could be dumped. >> > so mtrr_gran_size could do sth. >> > anyway this patch only can meet one end. >> > for example Mika Fischer's system doesn't need to trim any RAM in MTRR. >> > but for Gabriel's system may need to trim some RAM in MTRR. >> >> Right. Ram trimming (changing memory from WB to UC) is the potential >> problem. >> >> See my other post, in short I think we can address safely address all >> of the systems where the only problem is the selection of MTRRs by the >> BIOS. > > BIOS should provide the selection... The BIOS will setup which areas should be WB in the mtrrs. Having in the linux the ability to change from overlapping mtrrs to discrete mtrrs with BIOS support appears very practical, useful and always safe. >> Then have an option (mtrr_chunk_size) for RAM trimming that is >> off by default. > > Yes. there is CONFIG option and boot command line to enable it. However when it is enabled the default chunk size is still 256M. If we did not apply chunk size processing by default so we did not transform any regions from WB to UC by default we could unconditionally enable the code that yields discrete MTRRs. Then the CONFIG option and the command line option could be made to apply to the dangerous bits that change areas from WB to UC. Which I doubt we will want to have on by default but that can be useful for people who really want to have X go fast and an uncached SMM or ACPI area is not a problem. (ACPI we can handle by just copying the code to a cached area, we can't even discover the SMM area). Eric ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-26 12:56 ` Gabriel C 2008-04-27 1:05 ` Yinghai Lu @ 2008-04-28 6:44 ` Yinghai Lu 2008-04-28 9:18 ` Gabriel C 1 sibling, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-28 6:44 UTC (permalink / raw) To: Gabriel C Cc: Andrew Morton, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao, Andi Kleen On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote: > > Andrew Morton wrote: > > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: > > > >> [PATCH] x86_32: trim memory by updating e820 v3 > >> > >> when mtrr is not covering all e820 table, need to trim the ram, need to update e820 > >> > >> reuse some code for x86_64 > >> > >> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early > >> > >> need Justine to test with his special system with bug bios. > >> > >> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> > > > > Speaking of mtrr and e820.... > > > > Could someone please take a peek at > > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ? > > > > For some reason we seem to have turned this: > > > > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) > > [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) > > [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) > > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) > > [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) > > [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) > > [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) > > [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) > > [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) > > [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) > > [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) > > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > > [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) > > [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) > > > > into this: > > > > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 > > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 > > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > > > > which screws up the X server's attempt to map the video memory at > > 0xd0000000. > > I see that on my box with ASUS P5E-VM DO and 4G RAM. > It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS. > > I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit. > > Also I get the mtrr type mismatch message on 32 and 64 bit kernels. > > ... > > [ 0.000000] BIOS-provided physical RAM map: > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) > [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) > [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) > [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) > [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) > [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) > > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) > [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) > ... > > cat /proc/mtrr : > > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 > reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 > reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 please try the patch at http://lkml.org/lkml/2008/4/28/52 with mtrr_chunk_size=1g YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 6:44 ` Yinghai Lu @ 2008-04-28 9:18 ` Gabriel C 2008-04-28 9:34 ` Yinghai Lu 0 siblings, 1 reply; 87+ messages in thread From: Gabriel C @ 2008-04-28 9:18 UTC (permalink / raw) To: Yinghai Lu Cc: Andrew Morton, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao, Andi Kleen Yinghai Lu wrote: > On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote: >> Andrew Morton wrote: >> > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: >> > >> >> [PATCH] x86_32: trim memory by updating e820 v3 >> >> >> >> when mtrr is not covering all e820 table, need to trim the ram, need to update e820 >> >> >> >> reuse some code for x86_64 >> >> >> >> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early >> >> >> >> need Justine to test with his special system with bug bios. >> >> >> >> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> >> > >> > Speaking of mtrr and e820.... >> > >> > Could someone please take a peek at >> > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ? >> > >> > For some reason we seem to have turned this: >> > >> > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) >> > [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) >> > [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) >> > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) >> > [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) >> > [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) >> > [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) >> > [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) >> > [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) >> > [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) >> > [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) >> > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) >> > [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) >> > [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) >> > >> > into this: >> > >> > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 >> > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 >> > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 >> > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 >> > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 >> > >> > which screws up the X server's attempt to map the video memory at >> > 0xd0000000. >> >> I see that on my box with ASUS P5E-VM DO and 4G RAM. >> It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS. >> >> I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit. >> >> Also I get the mtrr type mismatch message on 32 and 64 bit kernels. >> >> ... >> >> [ 0.000000] BIOS-provided physical RAM map: >> [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) >> [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) >> [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) >> [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) >> [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) >> [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) >> [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) >> >> [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) >> [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) >> [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) >> ... >> >> cat /proc/mtrr : >> >> reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 >> reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 >> reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 >> reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 >> reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 >> reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 >> reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 > > please try the patch at > > http://lkml.org/lkml/2008/4/28/52 > > with mtrr_chunk_size=1g Hi, With mtrr_chunk_size=1g my box won't boot :( ( just tested 64bit kernel ). It does without but I get a warning: ... [ 0.000000] BIOS-provided physical RAM map: [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009cc00 (usable) [ 0.000000] BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved) [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) [ 0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used [ 0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used [ 0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used [ 0.000000] max_pfn_mapped = 1228800 [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] After WB checking [ 0.000000] MTRR MAP PFN: 0000000000000000 - 0000000000100000 [ 0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] After UC checking [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 [ 0.000000] After sorting [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf801000 - 00000000cf801000 [ 0.000000] range: 00000000cf801000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 4, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 5, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 6, base: 3320MB, range: 0MB, type WB [ 0.000000] Setting variable MTRR 7, base: 3320MB, range: 0MB, type WB [ 0.000000] range0: 0000000100001000 - 0000000110001000 [ 0.000000] range: 0000000110001000 - 0000000120001000 [ 0.000000] hole: 0000000120000000 - 0000000120001000 [ 0.000000] DONE variable MTRRs [ 0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106 [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1472MB of RAM. [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x154/0x18d() [ 0.000000] Modules linked in: [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.25-05561-g064922a-dirty #797 [ 0.000000] [ 0.000000] Call Trace: [ 0.000000] [<ffffffff802374f4>] warn_on_slowpath+0x64/0xb0 [ 0.000000] [<ffffffff8074ac5b>] mtrr_trim_uncached_memory+0x154/0x18d [ 0.000000] [<ffffffff80747a08>] setup_arch+0x356/0x599 [ 0.000000] [<ffffffff80740b6f>] start_kernel+0x5c/0x3b9 [ 0.000000] [<ffffffff80740425>] x86_64_start_kernel+0x225/0x270 [ 0.000000] [ 0.000000] ---[ end trace ca143223eefdc828 ]--- [ 0.000000] update e820 for mtrr [ 0.000000] modified physical RAM map: [ 0.000000] modified: 0000000000000000 - 000000000009cc00 (usable) [ 0.000000] modified: 000000000009cc00 - 00000000000a0000 (reserved) [ 0.000000] modified: 00000000000e4000 - 0000000000100000 (reserved) [ 0.000000] modified: 0000000000100000 - 00000000cf550000 (usable) [ 0.000000] modified: 00000000cf550000 - 00000000cf55e000 (ACPI data) [ 0.000000] modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) [ 0.000000] modified: 00000000cf5e0000 - 00000000cf600000 (reserved) [ 0.000000] modified: 00000000fee00000 - 00000000fee01000 (reserved) [ 0.000000] modified: 00000000ffc00000 - 000000012c000000 (reserved) [ 0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used [ 0.000000] Entering add_active_range(0, 256, 849232) 3 entries of 256 used [ 0.000000] max_pfn_mapped = 1228800 [ 0.000000] init_memory_mapping ... --($:~)-- cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1 reg03: base=0xcf801000 (3320MB), size= 4KB: write-back, count=1 reg04: base=0xcf802000 (3320MB), size= 8KB: write-back, count=1 reg05: base=0xcf804000 (3320MB), size= 16KB: write-back, count=1 reg06: base=0xcf808000 (3320MB), size= 32KB: write-back, count=1 reg07: base=0xcf810000 (3320MB), size= 64KB: write-back, count=1 --($:~)-- uname -a Linux thor 2.6.25-05561-g064922a-dirty #797 SMP PREEMPT Mon Apr 28 10:30:06 CEST 2008 x86_64 GNU/Linux Full dmesg can be found there : http://frugalware.org/~crazy/mtrr/mtrr_dmesg > > YH > Gabriel ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 9:18 ` Gabriel C @ 2008-04-28 9:34 ` Yinghai Lu 2008-04-28 9:54 ` Gabriel C 0 siblings, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-28 9:34 UTC (permalink / raw) To: Gabriel C Cc: Andrew Morton, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao, Andi Kleen On Mon, Apr 28, 2008 at 2:18 AM, Gabriel C <nix.or.die@googlemail.com> wrote: > > Yinghai Lu wrote: > > On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote: > >> Andrew Morton wrote: > >> > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: > >> > > >> >> [PATCH] x86_32: trim memory by updating e820 v3 > >> >> > >> >> when mtrr is not covering all e820 table, need to trim the ram, need to update e820 > >> >> > >> >> reuse some code for x86_64 > >> >> > >> >> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early > >> >> > >> >> need Justine to test with his special system with bug bios. > >> >> > >> >> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> > >> > > >> > Speaking of mtrr and e820.... > >> > > >> > Could someone please take a peek at > >> > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ? > >> > > >> > For some reason we seem to have turned this: > >> > > >> > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) > >> > [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) > >> > [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) > >> > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) > >> > [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) > >> > [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) > >> > [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) > >> > [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) > >> > [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) > >> > [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) > >> > [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) > >> > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > >> > [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) > >> > [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) > >> > > >> > into this: > >> > > >> > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 > >> > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > >> > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 > >> > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > >> > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > >> > > >> > which screws up the X server's attempt to map the video memory at > >> > 0xd0000000. > >> > >> I see that on my box with ASUS P5E-VM DO and 4G RAM. > >> It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS. > >> > >> I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit. > >> > >> Also I get the mtrr type mismatch message on 32 and 64 bit kernels. > >> > >> ... > >> > >> [ 0.000000] BIOS-provided physical RAM map: > >> [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) > >> [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) > >> [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) > >> [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) > >> [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) > >> [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) > >> [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) > >> > >> [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > >> [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) > >> [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) > >> ... > >> > >> cat /proc/mtrr : > >> > >> reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 > >> reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 > >> reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > >> reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 > >> reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 > >> reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 > >> reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 > > > > please try the patch at > > > > http://lkml.org/lkml/2008/4/28/52 > > > > with mtrr_chunk_size=1g > > Hi, > > With mtrr_chunk_size=1g my box won't boot :( ( just tested 64bit kernel ). > > It does without but I get a warning: > > > ... > > > [ 0.000000] BIOS-provided physical RAM map: > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009cc00 (usable) > [ 0.000000] BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved) > > [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) > [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) > [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) > [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) > [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) > [ 0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used > [ 0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used > [ 0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used > [ 0.000000] max_pfn_mapped = 1228800 > [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 > [ 0.000000] After WB checking > [ 0.000000] MTRR MAP PFN: 0000000000000000 - 0000000000100000 > [ 0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000120000 > [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 > [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 > [ 0.000000] After UC checking > [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 > [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 > [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 > [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 > [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 > [ 0.000000] After sorting > [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 > [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 > [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 > [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 > [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 > [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 > [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB > [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB > [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB > [ 0.000000] range0: 00000000cf801000 - 00000000cf801000 > [ 0.000000] range: 00000000cf801000 - 00000000d0000000 > [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 0MB, type WB > [ 0.000000] Setting variable MTRR 4, base: 3320MB, range: 0MB, type WB > [ 0.000000] Setting variable MTRR 5, base: 3320MB, range: 0MB, type WB > [ 0.000000] Setting variable MTRR 6, base: 3320MB, range: 0MB, type WB > [ 0.000000] Setting variable MTRR 7, base: 3320MB, range: 0MB, type WB > [ 0.000000] range0: 0000000100001000 - 0000000110001000 > [ 0.000000] range: 0000000110001000 - 0000000120001000 > [ 0.000000] hole: 0000000120000000 - 0000000120001000 > [ 0.000000] DONE variable MTRRs > [ 0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106 > [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1472MB of RAM. > [ 0.000000] ------------[ cut here ]------------ > [ 0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x154/0x18d() > > [ 0.000000] Modules linked in: > [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.25-05561-g064922a-dirty #797 > [ 0.000000] > [ 0.000000] Call Trace: > [ 0.000000] [<ffffffff802374f4>] warn_on_slowpath+0x64/0xb0 > [ 0.000000] [<ffffffff8074ac5b>] mtrr_trim_uncached_memory+0x154/0x18d > [ 0.000000] [<ffffffff80747a08>] setup_arch+0x356/0x599 > [ 0.000000] [<ffffffff80740b6f>] start_kernel+0x5c/0x3b9 > [ 0.000000] [<ffffffff80740425>] x86_64_start_kernel+0x225/0x270 > > [ 0.000000] > [ 0.000000] ---[ end trace ca143223eefdc828 ]--- > [ 0.000000] update e820 for mtrr > [ 0.000000] modified physical RAM map: > [ 0.000000] modified: 0000000000000000 - 000000000009cc00 (usable) > [ 0.000000] modified: 000000000009cc00 - 00000000000a0000 (reserved) > [ 0.000000] modified: 00000000000e4000 - 0000000000100000 (reserved) > [ 0.000000] modified: 0000000000100000 - 00000000cf550000 (usable) > [ 0.000000] modified: 00000000cf550000 - 00000000cf55e000 (ACPI data) > [ 0.000000] modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) > [ 0.000000] modified: 00000000cf5e0000 - 00000000cf600000 (reserved) > [ 0.000000] modified: 00000000fee00000 - 00000000fee01000 (reserved) > [ 0.000000] modified: 00000000ffc00000 - 000000012c000000 (reserved) > [ 0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used > [ 0.000000] Entering add_active_range(0, 256, 849232) 3 entries of 256 used > [ 0.000000] max_pfn_mapped = 1228800 > [ 0.000000] init_memory_mapping > > ... > > > --($:~)-- cat /proc/mtrr > > reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 > reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 > reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1 > reg03: base=0xcf801000 (3320MB), size= 4KB: write-back, count=1 > reg04: base=0xcf802000 (3320MB), size= 8KB: write-back, count=1 > reg05: base=0xcf804000 (3320MB), size= 16KB: write-back, count=1 > reg06: base=0xcf808000 (3320MB), size= 32KB: write-back, count=1 > reg07: base=0xcf810000 (3320MB), size= 64KB: write-back, count=1 > > --($:~)-- uname -a > Linux thor 2.6.25-05561-g064922a-dirty #797 SMP PREEMPT Mon Apr 28 10:30:06 CEST 2008 x86_64 GNU/Linux > > Full dmesg can be found there : > > > http://frugalware.org/~crazy/mtrr/mtrr_dmesg please try v2 version http://lkml.org/lkml/2008/4/28/115 YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 9:34 ` Yinghai Lu @ 2008-04-28 9:54 ` Gabriel C 2008-04-28 10:03 ` Gabriel C 2008-04-28 13:53 ` Ingo Molnar 0 siblings, 2 replies; 87+ messages in thread From: Gabriel C @ 2008-04-28 9:54 UTC (permalink / raw) To: Yinghai Lu Cc: Andrew Morton, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao, Andi Kleen Yinghai Lu wrote: > On Mon, Apr 28, 2008 at 2:18 AM, Gabriel C <nix.or.die@googlemail.com> wrote: >> Yinghai Lu wrote: >> > On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote: >> >> Andrew Morton wrote: >> >> > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: >> >> > >> >> >> [PATCH] x86_32: trim memory by updating e820 v3 >> >> >> >> >> >> when mtrr is not covering all e820 table, need to trim the ram, need to update e820 >> >> >> >> >> >> reuse some code for x86_64 >> >> >> >> >> >> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early >> >> >> >> >> >> need Justine to test with his special system with bug bios. >> >> >> >> >> >> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> >> >> > >> >> > Speaking of mtrr and e820.... >> >> > >> >> > Could someone please take a peek at >> >> > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ? >> >> > >> >> > For some reason we seem to have turned this: >> >> > >> >> > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) >> >> > [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) >> >> > [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) >> >> > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) >> >> > [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) >> >> > [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) >> >> > [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) >> >> > [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) >> >> > [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) >> >> > [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) >> >> > [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) >> >> > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) >> >> > [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) >> >> > [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) >> >> > >> >> > into this: >> >> > >> >> > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 >> >> > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 >> >> > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 >> >> > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 >> >> > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 >> >> > >> >> > which screws up the X server's attempt to map the video memory at >> >> > 0xd0000000. >> >> >> >> I see that on my box with ASUS P5E-VM DO and 4G RAM. >> >> It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS. >> >> >> >> I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit. >> >> >> >> Also I get the mtrr type mismatch message on 32 and 64 bit kernels. >> >> >> >> ... >> >> >> >> [ 0.000000] BIOS-provided physical RAM map: >> >> [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) >> >> [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) >> >> [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) >> >> [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) >> >> [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) >> >> [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) >> >> [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) >> >> >> >> [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) >> >> [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) >> >> [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) >> >> ... >> >> >> >> cat /proc/mtrr : >> >> >> >> reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 >> >> reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 >> >> reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 >> >> reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 >> >> reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 >> >> reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 >> >> reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 >> > >> > please try the patch at >> > >> > http://lkml.org/lkml/2008/4/28/52 >> > >> > with mtrr_chunk_size=1g >> >> Hi, >> >> With mtrr_chunk_size=1g my box won't boot :( ( just tested 64bit kernel ). >> >> It does without but I get a warning: >> >> >> ... >> >> >> [ 0.000000] BIOS-provided physical RAM map: >> [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009cc00 (usable) >> [ 0.000000] BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved) >> >> [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) >> [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) >> [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) >> [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) >> [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) >> [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) >> [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) >> [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) >> [ 0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used >> [ 0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used >> [ 0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used >> [ 0.000000] max_pfn_mapped = 1228800 >> [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 >> [ 0.000000] After WB checking >> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 0000000000100000 >> [ 0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000120000 >> [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 >> [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 >> [ 0.000000] After UC checking >> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 >> [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 >> [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 >> [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 >> [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 >> [ 0.000000] After sorting >> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 >> [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 >> [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 >> [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 >> [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 >> [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 >> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB >> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB >> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB >> [ 0.000000] range0: 00000000cf801000 - 00000000cf801000 >> [ 0.000000] range: 00000000cf801000 - 00000000d0000000 >> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 0MB, type WB >> [ 0.000000] Setting variable MTRR 4, base: 3320MB, range: 0MB, type WB >> [ 0.000000] Setting variable MTRR 5, base: 3320MB, range: 0MB, type WB >> [ 0.000000] Setting variable MTRR 6, base: 3320MB, range: 0MB, type WB >> [ 0.000000] Setting variable MTRR 7, base: 3320MB, range: 0MB, type WB >> [ 0.000000] range0: 0000000100001000 - 0000000110001000 >> [ 0.000000] range: 0000000110001000 - 0000000120001000 >> [ 0.000000] hole: 0000000120000000 - 0000000120001000 >> [ 0.000000] DONE variable MTRRs >> [ 0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106 >> [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1472MB of RAM. >> [ 0.000000] ------------[ cut here ]------------ >> [ 0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x154/0x18d() >> >> [ 0.000000] Modules linked in: >> [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.25-05561-g064922a-dirty #797 >> [ 0.000000] >> [ 0.000000] Call Trace: >> [ 0.000000] [<ffffffff802374f4>] warn_on_slowpath+0x64/0xb0 >> [ 0.000000] [<ffffffff8074ac5b>] mtrr_trim_uncached_memory+0x154/0x18d >> [ 0.000000] [<ffffffff80747a08>] setup_arch+0x356/0x599 >> [ 0.000000] [<ffffffff80740b6f>] start_kernel+0x5c/0x3b9 >> [ 0.000000] [<ffffffff80740425>] x86_64_start_kernel+0x225/0x270 >> >> [ 0.000000] >> [ 0.000000] ---[ end trace ca143223eefdc828 ]--- >> [ 0.000000] update e820 for mtrr >> [ 0.000000] modified physical RAM map: >> [ 0.000000] modified: 0000000000000000 - 000000000009cc00 (usable) >> [ 0.000000] modified: 000000000009cc00 - 00000000000a0000 (reserved) >> [ 0.000000] modified: 00000000000e4000 - 0000000000100000 (reserved) >> [ 0.000000] modified: 0000000000100000 - 00000000cf550000 (usable) >> [ 0.000000] modified: 00000000cf550000 - 00000000cf55e000 (ACPI data) >> [ 0.000000] modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) >> [ 0.000000] modified: 00000000cf5e0000 - 00000000cf600000 (reserved) >> [ 0.000000] modified: 00000000fee00000 - 00000000fee01000 (reserved) >> [ 0.000000] modified: 00000000ffc00000 - 000000012c000000 (reserved) >> [ 0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used >> [ 0.000000] Entering add_active_range(0, 256, 849232) 3 entries of 256 used >> [ 0.000000] max_pfn_mapped = 1228800 >> [ 0.000000] init_memory_mapping >> >> ... >> >> >> --($:~)-- cat /proc/mtrr >> >> reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 >> reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 >> reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1 >> reg03: base=0xcf801000 (3320MB), size= 4KB: write-back, count=1 >> reg04: base=0xcf802000 (3320MB), size= 8KB: write-back, count=1 >> reg05: base=0xcf804000 (3320MB), size= 16KB: write-back, count=1 >> reg06: base=0xcf808000 (3320MB), size= 32KB: write-back, count=1 >> reg07: base=0xcf810000 (3320MB), size= 64KB: write-back, count=1 >> >> --($:~)-- uname -a >> Linux thor 2.6.25-05561-g064922a-dirty #797 SMP PREEMPT Mon Apr 28 10:30:06 CEST 2008 x86_64 GNU/Linux >> >> Full dmesg can be found there : >> >> >> http://frugalware.org/~crazy/mtrr/mtrr_dmesg > > please try v2 version > > http://lkml.org/lkml/2008/4/28/115 Box still won't boot with mtrr_chunk_size=1g but without it is perfect :)) Thx for your work. I've quick tested some games and 3d things , all are working with this patch really nice. Full dmesg : http://frugalware.org/~crazy/mtrr/mtrr2_dmesg --($:~)-- cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1 reg03: base=0xcf800000 (3320MB), size= 8MB: write-back, count=1 reg04: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg05: base=0x120000000 (4608MB), size= 256MB: write-back, count=1 reg06: base=0x12c000000 (4800MB), size= 64MB: uncachable, count=1 reg07: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1 If you wish I can test 32bit too a bit later , just let me know. > > YH > Gabriel ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 9:54 ` Gabriel C @ 2008-04-28 10:03 ` Gabriel C 2008-04-28 10:07 ` Mika Fischer 2008-04-28 13:53 ` Ingo Molnar 1 sibling, 1 reply; 87+ messages in thread From: Gabriel C @ 2008-04-28 10:03 UTC (permalink / raw) To: Yinghai Lu Cc: Andrew Morton, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao, Andi Kleen Gabriel C wrote: > Yinghai Lu wrote: >> On Mon, Apr 28, 2008 at 2:18 AM, Gabriel C <nix.or.die@googlemail.com> wrote: >>> Yinghai Lu wrote: >>> > On Sat, Apr 26, 2008 at 5:56 AM, Gabriel C <nix.or.die@googlemail.com> wrote: >>> >> Andrew Morton wrote: >>> >> > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: >>> >> > >>> >> >> [PATCH] x86_32: trim memory by updating e820 v3 >>> >> >> >>> >> >> when mtrr is not covering all e820 table, need to trim the ram, need to update e820 >>> >> >> >>> >> >> reuse some code for x86_64 >>> >> >> >>> >> >> here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early >>> >> >> >>> >> >> need Justine to test with his special system with bug bios. >>> >> >> >>> >> >> Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> >>> >> > >>> >> > Speaking of mtrr and e820.... >>> >> > >>> >> > Could someone please take a peek at >>> >> > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ? >>> >> > >>> >> > For some reason we seem to have turned this: >>> >> > >>> >> > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) >>> >> > [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) >>> >> > [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) >>> >> > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) >>> >> > [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) >>> >> > [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) >>> >> > [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) >>> >> > [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) >>> >> > [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) >>> >> > [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) >>> >> > [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) >>> >> > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) >>> >> > [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) >>> >> > [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) >>> >> > >>> >> > into this: >>> >> > >>> >> > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 >>> >> > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 >>> >> > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 >>> >> > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 >>> >> > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 >>> >> > >>> >> > which screws up the X server's attempt to map the video memory at >>> >> > 0xd0000000. >>> >> >>> >> I see that on my box with ASUS P5E-VM DO and 4G RAM. >>> >> It has an Q35 intel chipset and the intel card is set to use 256MB in BIOS. >>> >> >>> >> I tested 2.6.{24*,25,25-next,25-latest-git} 32/64 bit. >>> >> >>> >> Also I get the mtrr type mismatch message on 32 and 64 bit kernels. >>> >> >>> >> ... >>> >> >>> >> [ 0.000000] BIOS-provided physical RAM map: >>> >> [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009ec00 (usable) >>> >> [ 0.000000] BIOS-e820: 000000000009ec00 - 00000000000a0000 (reserved) >>> >> [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) >>> >> [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) >>> >> [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) >>> >> [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) >>> >> [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) >>> >> >>> >> [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) >>> >> [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) >>> >> [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) >>> >> ... >>> >> >>> >> cat /proc/mtrr : >>> >> >>> >> reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 >>> >> reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 >>> >> reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 >>> >> reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 >>> >> reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 >>> >> reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 >>> >> reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 >>> > >>> > please try the patch at >>> > >>> > http://lkml.org/lkml/2008/4/28/52 >>> > >>> > with mtrr_chunk_size=1g >>> >>> Hi, >>> >>> With mtrr_chunk_size=1g my box won't boot :( ( just tested 64bit kernel ). >>> >>> It does without but I get a warning: >>> >>> >>> ... >>> >>> >>> [ 0.000000] BIOS-provided physical RAM map: >>> [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009cc00 (usable) >>> [ 0.000000] BIOS-e820: 000000000009cc00 - 00000000000a0000 (reserved) >>> >>> [ 0.000000] BIOS-e820: 00000000000e4000 - 0000000000100000 (reserved) >>> [ 0.000000] BIOS-e820: 0000000000100000 - 00000000cf550000 (usable) >>> [ 0.000000] BIOS-e820: 00000000cf550000 - 00000000cf55e000 (ACPI data) >>> [ 0.000000] BIOS-e820: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) >>> [ 0.000000] BIOS-e820: 00000000cf5e0000 - 00000000cf600000 (reserved) >>> [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) >>> [ 0.000000] BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved) >>> [ 0.000000] BIOS-e820: 0000000100000000 - 000000012c000000 (usable) >>> [ 0.000000] Entering add_active_range(0, 0, 156) 0 entries of 256 used >>> [ 0.000000] Entering add_active_range(0, 256, 849232) 1 entries of 256 used >>> [ 0.000000] Entering add_active_range(0, 1048576, 1228800) 2 entries of 256 used >>> [ 0.000000] max_pfn_mapped = 1228800 >>> [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 >>> [ 0.000000] After WB checking >>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 0000000000100000 >>> [ 0.000000] MTRR MAP PFN: 0000000000100000 - 0000000000120000 >>> [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 >>> [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 >>> [ 0.000000] After UC checking >>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 >>> [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 >>> [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 >>> [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 >>> [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 >>> [ 0.000000] After sorting >>> [ 0.000000] MTRR MAP PFN: 0000000000000000 - 00000000000cf600 >>> [ 0.000000] MTRR MAP PFN: 00000000000cf801 - 00000000000d0000 >>> [ 0.000000] MTRR MAP PFN: 0000000000100001 - 0000000000120000 >>> [ 0.000000] MTRR MAP PFN: 0000000000120000 - 0000000000128000 >>> [ 0.000000] MTRR MAP PFN: 0000000000128000 - 000000000012c000 >>> [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 >>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB >>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB >>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB >>> [ 0.000000] range0: 00000000cf801000 - 00000000cf801000 >>> [ 0.000000] range: 00000000cf801000 - 00000000d0000000 >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 0MB, type WB >>> [ 0.000000] Setting variable MTRR 4, base: 3320MB, range: 0MB, type WB >>> [ 0.000000] Setting variable MTRR 5, base: 3320MB, range: 0MB, type WB >>> [ 0.000000] Setting variable MTRR 6, base: 3320MB, range: 0MB, type WB >>> [ 0.000000] Setting variable MTRR 7, base: 3320MB, range: 0MB, type WB >>> [ 0.000000] range0: 0000000100001000 - 0000000110001000 >>> [ 0.000000] range: 0000000110001000 - 0000000120001000 >>> [ 0.000000] hole: 0000000120000000 - 0000000120001000 >>> [ 0.000000] DONE variable MTRRs >>> [ 0.000000] x86 PAT enabled: cpu 0, old 0x7010600070106, new 0x7010600070106 >>> [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1472MB of RAM. >>> [ 0.000000] ------------[ cut here ]------------ >>> [ 0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x154/0x18d() >>> >>> [ 0.000000] Modules linked in: >>> [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.25-05561-g064922a-dirty #797 >>> [ 0.000000] >>> [ 0.000000] Call Trace: >>> [ 0.000000] [<ffffffff802374f4>] warn_on_slowpath+0x64/0xb0 >>> [ 0.000000] [<ffffffff8074ac5b>] mtrr_trim_uncached_memory+0x154/0x18d >>> [ 0.000000] [<ffffffff80747a08>] setup_arch+0x356/0x599 >>> [ 0.000000] [<ffffffff80740b6f>] start_kernel+0x5c/0x3b9 >>> [ 0.000000] [<ffffffff80740425>] x86_64_start_kernel+0x225/0x270 >>> >>> [ 0.000000] >>> [ 0.000000] ---[ end trace ca143223eefdc828 ]--- >>> [ 0.000000] update e820 for mtrr >>> [ 0.000000] modified physical RAM map: >>> [ 0.000000] modified: 0000000000000000 - 000000000009cc00 (usable) >>> [ 0.000000] modified: 000000000009cc00 - 00000000000a0000 (reserved) >>> [ 0.000000] modified: 00000000000e4000 - 0000000000100000 (reserved) >>> [ 0.000000] modified: 0000000000100000 - 00000000cf550000 (usable) >>> [ 0.000000] modified: 00000000cf550000 - 00000000cf55e000 (ACPI data) >>> [ 0.000000] modified: 00000000cf55e000 - 00000000cf5e0000 (ACPI NVS) >>> [ 0.000000] modified: 00000000cf5e0000 - 00000000cf600000 (reserved) >>> [ 0.000000] modified: 00000000fee00000 - 00000000fee01000 (reserved) >>> [ 0.000000] modified: 00000000ffc00000 - 000000012c000000 (reserved) >>> [ 0.000000] Entering add_active_range(0, 0, 156) 3 entries of 256 used >>> [ 0.000000] Entering add_active_range(0, 256, 849232) 3 entries of 256 used >>> [ 0.000000] max_pfn_mapped = 1228800 >>> [ 0.000000] init_memory_mapping >>> >>> ... >>> >>> >>> --($:~)-- cat /proc/mtrr >>> >>> reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 >>> reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 >>> reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1 >>> reg03: base=0xcf801000 (3320MB), size= 4KB: write-back, count=1 >>> reg04: base=0xcf802000 (3320MB), size= 8KB: write-back, count=1 >>> reg05: base=0xcf804000 (3320MB), size= 16KB: write-back, count=1 >>> reg06: base=0xcf808000 (3320MB), size= 32KB: write-back, count=1 >>> reg07: base=0xcf810000 (3320MB), size= 64KB: write-back, count=1 >>> >>> --($:~)-- uname -a >>> Linux thor 2.6.25-05561-g064922a-dirty #797 SMP PREEMPT Mon Apr 28 10:30:06 CEST 2008 x86_64 GNU/Linux >>> >>> Full dmesg can be found there : >>> >>> >>> http://frugalware.org/~crazy/mtrr/mtrr_dmesg >> please try v2 version >> >> http://lkml.org/lkml/2008/4/28/115 > > Box still won't boot with mtrr_chunk_size=1g but without it is perfect :)) Thx for your work. > I've quick tested some games and 3d things , all are working with this patch really nice. > > Full dmesg : > > http://frugalware.org/~crazy/mtrr/mtrr2_dmesg > > > --($:~)-- cat /proc/mtrr > reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 > reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 > reg02: base=0xc0000000 (3072MB), size= 256MB: write-back, count=1 > reg03: base=0xcf800000 (3320MB), size= 8MB: write-back, count=1 > reg04: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 > reg05: base=0x120000000 (4608MB), size= 256MB: write-back, count=1 > reg06: base=0x12c000000 (4800MB), size= 64MB: uncachable, count=1 > reg07: base=0xd0000000 (3328MB), size= 256MB: write-combining, count=1 > > > If you wish I can test 32bit too a bit later , just let me know. BTW I just saw , there is this warning now : [ 0.305539] mtrr: your CPUs had inconsistent variable MTRR settings [ 0.305546] mtrr: probably your BIOS does not setup all CPUs. [ 0.305553] mtrr: corrected configuration. but everything seems to work fine. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 10:03 ` Gabriel C @ 2008-04-28 10:07 ` Mika Fischer 2008-04-28 19:03 ` Yinghai Lu 0 siblings, 1 reply; 87+ messages in thread From: Mika Fischer @ 2008-04-28 10:07 UTC (permalink / raw) To: Gabriel C Cc: Yinghai Lu, Andrew Morton, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen Gabriel C schrieb: > BTW I just saw , there is this warning now : > > [ 0.305539] mtrr: your CPUs had inconsistent variable MTRR settings > [ 0.305546] mtrr: probably your BIOS does not setup all CPUs. > [ 0.305553] mtrr: corrected configuration. > > but everything seems to work fine. Just, FYI, I got this warning too. I didn't get it before applying the patch. Regards, Mika ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 10:07 ` Mika Fischer @ 2008-04-28 19:03 ` Yinghai Lu 0 siblings, 0 replies; 87+ messages in thread From: Yinghai Lu @ 2008-04-28 19:03 UTC (permalink / raw) To: Mika Fischer Cc: Gabriel C, Andrew Morton, Ingo Molnar, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen On Mon, Apr 28, 2008 at 3:07 AM, Mika Fischer <mika.fischer@zoopnet.de> wrote: > Gabriel C schrieb: > > > BTW I just saw , there is this warning now : > > > > [ 0.305539] mtrr: your CPUs had inconsistent variable MTRR settings > > [ 0.305546] mtrr: probably your BIOS does not setup all CPUs. > > [ 0.305553] mtrr: corrected configuration. > > > > but everything seems to work fine. > > Just, FYI, I got this warning too. I didn't get it before applying the patch. that is normal. because APs will copy the changes of MTRR from BP. could add some condition for the print out. YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 9:54 ` Gabriel C 2008-04-28 10:03 ` Gabriel C @ 2008-04-28 13:53 ` Ingo Molnar 2008-04-28 14:11 ` Mika Fischer ` (2 more replies) 1 sibling, 3 replies; 87+ messages in thread From: Ingo Molnar @ 2008-04-28 13:53 UTC (permalink / raw) To: Gabriel C Cc: Yinghai Lu, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao, Andi Kleen, Thomas Gleixner * Gabriel C <nix.or.die@googlemail.com> wrote: > > please try v2 version > > > > http://lkml.org/lkml/2008/4/28/115 > > Box still won't boot with mtrr_chunk_size=1g but without it is perfect > :)) Thx for your work. I've quick tested some games and 3d things , > all are working with this patch really nice. excellent. So just to make sure: this box never had proper graphics under Linux (under no previous kernel), due to the way the BIOS has set up the MTRR's, right? so fixing up the MTRRs during bootup, no matter how dangerous in theory, is pretty much the best option to get your system to work fine under Linux, with that specific Xorg version? i think we should still try to make this a non-default option because modern Xorg should not have any need to touch MTRRs. Perhaps a .config dependent on CONFIG_DANGEROUS ;-) Ingo ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 13:53 ` Ingo Molnar @ 2008-04-28 14:11 ` Mika Fischer 2008-04-28 14:24 ` Gabriel C 2008-04-28 14:15 ` Gabriel C 2008-04-28 16:09 ` Jesse Barnes 2 siblings, 1 reply; 87+ messages in thread From: Mika Fischer @ 2008-04-28 14:11 UTC (permalink / raw) To: Ingo Molnar Cc: Gabriel C, Yinghai Lu, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner Hi Ingo, I'm having the same problem. Ingo Molnar schrieb: > excellent. So just to make sure: this box never had proper graphics > under Linux (under no previous kernel), due to the way the BIOS has set > up the MTRR's, right? Well, not quite. X still works fine, but since the video memory is overlapped by two of the existing MTRRs, X cannot add a write-combining range for the video memory. That makes X rather slow especially if you use DRI for Compiz etc. And this always happens with 4GB RAM, but not with 2GB RAM. So yes, with this patch for the first time X works at normal speed with 4GB of RAM out of the box. > so fixing up the MTRRs during bootup, no matter how dangerous in theory, > is pretty much the best option to get your system to work fine under > Linux, with that specific Xorg version? Yes. That's what I'm doing at the moment with a shell script. :) > i think we should still try to make this a non-default option because > modern Xorg should not have any need to touch MTRRs. Perhaps a .config > dependent on CONFIG_DANGEROUS ;-) AFAICT X always tries to set up a write-combining range for the video memory. And this will always fail if there are erroneous write-back or even uncachable ranges overlapping the video memory... But I don't know if this has changed in newer versions of Xorg (I'm using 7.3). In any case if I have a range in /proc/mtrr that is declared uncachable and overlaps my video memory (which is the case without this patch), is there even anything Xorg can do to make the video-memory use write-combining? Regards, Mika ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 14:11 ` Mika Fischer @ 2008-04-28 14:24 ` Gabriel C 2008-04-28 19:06 ` Yinghai Lu 2008-04-28 19:08 ` Yinghai Lu 0 siblings, 2 replies; 87+ messages in thread From: Gabriel C @ 2008-04-28 14:24 UTC (permalink / raw) To: Mika Fischer Cc: Ingo Molnar, Yinghai Lu, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner Mika Fischer wrote: > Hi Ingo, > > I'm having the same problem. > > Ingo Molnar schrieb: >> excellent. So just to make sure: this box never had proper graphics >> under Linux (under no previous kernel), due to the way the BIOS has set >> up the MTRR's, right? > > Well, not quite. X still works fine, but since the video memory is > overlapped by two of the existing MTRRs, X cannot add a write-combining > range for the video memory. That makes X rather slow especially if you > use DRI for Compiz etc. Well you are lucky then :) Yeah X 'worked' but it worked as slow as with vesa video driver here. Also starting something like supertuxkart made it crash or I got a black screen :( The only game I managed to start ( without X to crash ) without that patch was supertux but is was slow as hell. However I'm not a gamer but I need X to work right. > Regards, > Mika > Gabriel ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 14:24 ` Gabriel C @ 2008-04-28 19:06 ` Yinghai Lu 2008-04-28 19:38 ` Gabriel C 2008-04-28 19:08 ` Yinghai Lu 1 sibling, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-28 19:06 UTC (permalink / raw) To: Gabriel C Cc: Mika Fischer, Ingo Molnar, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote: > Mika Fischer wrote: > > Hi Ingo, > > > > I'm having the same problem. > > > > Ingo Molnar schrieb: > >> excellent. So just to make sure: this box never had proper graphics > >> under Linux (under no previous kernel), due to the way the BIOS has set > >> up the MTRR's, right? > > > > Well, not quite. X still works fine, but since the video memory is > > overlapped by two of the existing MTRRs, X cannot add a write-combining > > range for the video memory. That makes X rather slow especially if you > > use DRI for Compiz etc. > > Well you are lucky then :) > > Yeah X 'worked' but it worked as slow as with vesa video driver here. [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 [ 0.000000] range: 00000000cf800000 - 00000000d0000000 [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB [ 0.000000] range0: 0000000100000000 - 0000000120000000 [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB [ 0.000000] range: 0000000120000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB [ 0.000000] hole: 000000012c000000 - 0000000130000000 [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC so your X server need two entries for WB? can you send out /proc/mtrr with booting with disable_mtrr_cleanup? YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 19:06 ` Yinghai Lu @ 2008-04-28 19:38 ` Gabriel C 2008-04-28 20:45 ` Gabriel C 0 siblings, 1 reply; 87+ messages in thread From: Gabriel C @ 2008-04-28 19:38 UTC (permalink / raw) To: Yinghai Lu Cc: Mika Fischer, Ingo Molnar, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner Yinghai Lu wrote: > On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote: >> Mika Fischer wrote: >> > Hi Ingo, >> > >> > I'm having the same problem. >> > >> > Ingo Molnar schrieb: >> >> excellent. So just to make sure: this box never had proper graphics >> >> under Linux (under no previous kernel), due to the way the BIOS has set >> >> up the MTRR's, right? >> > >> > Well, not quite. X still works fine, but since the video memory is >> > overlapped by two of the existing MTRRs, X cannot add a write-combining >> > range for the video memory. That makes X rather slow especially if you >> > use DRI for Compiz etc. >> >> Well you are lucky then :) >> >> Yeah X 'worked' but it worked as slow as with vesa video driver here. > > [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 > [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB > [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB > [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB > [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 > [ 0.000000] range: 00000000cf800000 - 00000000d0000000 > [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB > [ 0.000000] range0: 0000000100000000 - 0000000120000000 > [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB > [ 0.000000] range: 0000000120000000 - 0000000130000000 > [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB > [ 0.000000] hole: 000000012c000000 - 0000000130000000 > [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC > > so your X server need two entries for WB? > > can you send out /proc/mtrr with booting with disable_mtrr_cleanup? I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less. > > YH > Gabriel ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 19:38 ` Gabriel C @ 2008-04-28 20:45 ` Gabriel C 2008-04-28 21:19 ` Gabriel C 0 siblings, 1 reply; 87+ messages in thread From: Gabriel C @ 2008-04-28 20:45 UTC (permalink / raw) To: Yinghai Lu Cc: Mika Fischer, Ingo Molnar, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner Gabriel C wrote: > Yinghai Lu wrote: >> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote: >>> Mika Fischer wrote: >>> > Hi Ingo, >>> > >>> > I'm having the same problem. >>> > >>> > Ingo Molnar schrieb: >>> >> excellent. So just to make sure: this box never had proper graphics >>> >> under Linux (under no previous kernel), due to the way the BIOS has set >>> >> up the MTRR's, right? >>> > >>> > Well, not quite. X still works fine, but since the video memory is >>> > overlapped by two of the existing MTRRs, X cannot add a write-combining >>> > range for the video memory. That makes X rather slow especially if you >>> > use DRI for Compiz etc. >>> >>> Well you are lucky then :) >>> >>> Yeah X 'worked' but it worked as slow as with vesa video driver here. >> [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 >> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB >> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB >> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB >> [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 >> [ 0.000000] range: 00000000cf800000 - 00000000d0000000 >> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB >> [ 0.000000] range0: 0000000100000000 - 0000000120000000 >> [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB >> [ 0.000000] range: 0000000120000000 - 0000000130000000 >> [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB >> [ 0.000000] hole: 000000012c000000 - 0000000130000000 >> [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC >> >> so your X server need two entries for WB? >> >> can you send out /proc/mtrr with booting with disable_mtrr_cleanup? > > I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less. Here the output with v3 which is disabled by default: --($:~)-- cat /proc/mtrr reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 dmesg is saying now : [ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining My card settings in BIOS ( that was default ) are the following : DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT ) Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD ) Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) PEG Port -> Auto ( possible settings Auto , Disabled ) PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled ) Of course these settings are only possible when the card is not disabled :) I'm gonna try v4 now and enable it. Please let me know if you need more infos. Gabriel ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 20:45 ` Gabriel C @ 2008-04-28 21:19 ` Gabriel C 2008-04-28 22:03 ` Yinghai Lu 0 siblings, 1 reply; 87+ messages in thread From: Gabriel C @ 2008-04-28 21:19 UTC (permalink / raw) To: Yinghai Lu Cc: Mika Fischer, Ingo Molnar, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner Gabriel C wrote: > Gabriel C wrote: >> Yinghai Lu wrote: >>> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote: >>>> Mika Fischer wrote: >>>> > Hi Ingo, >>>> > >>>> > I'm having the same problem. >>>> > >>>> > Ingo Molnar schrieb: >>>> >> excellent. So just to make sure: this box never had proper graphics >>>> >> under Linux (under no previous kernel), due to the way the BIOS has set >>>> >> up the MTRR's, right? >>>> > >>>> > Well, not quite. X still works fine, but since the video memory is >>>> > overlapped by two of the existing MTRRs, X cannot add a write-combining >>>> > range for the video memory. That makes X rather slow especially if you >>>> > use DRI for Compiz etc. >>>> >>>> Well you are lucky then :) >>>> >>>> Yeah X 'worked' but it worked as slow as with vesa video driver here. >>> [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 >>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB >>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB >>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB >>> [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 >>> [ 0.000000] range: 00000000cf800000 - 00000000d0000000 >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB >>> [ 0.000000] range0: 0000000100000000 - 0000000120000000 >>> [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB >>> [ 0.000000] range: 0000000120000000 - 0000000130000000 >>> [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB >>> [ 0.000000] hole: 000000012c000000 - 0000000130000000 >>> [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC >>> >>> so your X server need two entries for WB? >>> >>> can you send out /proc/mtrr with booting with disable_mtrr_cleanup? >> I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less. > > Here the output with v3 which is disabled by default: > > --($:~)-- cat /proc/mtrr > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 > reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 > reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 > > dmesg is saying now : > > [ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining > > > My card settings in BIOS ( that was default ) are the following : > > DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) > DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT ) > > Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD ) > Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) > PEG Port -> Auto ( possible settings Auto , Disabled ) > PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled ) > > Of course these settings are only possible when the card is not disabled :) > > I'm gonna try v4 now and enable it. Please let me know if you need more infos. Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ). It takes 6 minutes to boot to : sr0: scsi3-mmc drive: 48x/48x writer dvd-ram cd/rw xa/form2 cdda tray after that the box hangs :/ ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 21:19 ` Gabriel C @ 2008-04-28 22:03 ` Yinghai Lu 2008-04-28 22:56 ` Gabriel C 0 siblings, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-28 22:03 UTC (permalink / raw) To: Gabriel C Cc: Mika Fischer, Ingo Molnar, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner On Mon, Apr 28, 2008 at 2:19 PM, Gabriel C <nix.or.die@googlemail.com> wrote: > > Gabriel C wrote: > > Gabriel C wrote: > >> Yinghai Lu wrote: > >>> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote: > >>>> Mika Fischer wrote: > >>>> > Hi Ingo, > >>>> > > >>>> > I'm having the same problem. > >>>> > > >>>> > Ingo Molnar schrieb: > >>>> >> excellent. So just to make sure: this box never had proper graphics > >>>> >> under Linux (under no previous kernel), due to the way the BIOS has set > >>>> >> up the MTRR's, right? > >>>> > > >>>> > Well, not quite. X still works fine, but since the video memory is > >>>> > overlapped by two of the existing MTRRs, X cannot add a write-combining > >>>> > range for the video memory. That makes X rather slow especially if you > >>>> > use DRI for Compiz etc. > >>>> > >>>> Well you are lucky then :) > >>>> > >>>> Yeah X 'worked' but it worked as slow as with vesa video driver here. > >>> [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 > >>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB > >>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB > >>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB > >>> [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 > >>> [ 0.000000] range: 00000000cf800000 - 00000000d0000000 > >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB > >>> [ 0.000000] range0: 0000000100000000 - 0000000120000000 > >>> [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB > >>> [ 0.000000] range: 0000000120000000 - 0000000130000000 > >>> [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB > >>> [ 0.000000] hole: 000000012c000000 - 0000000130000000 > >>> [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC > >>> > >>> so your X server need two entries for WB? > >>> > >>> can you send out /proc/mtrr with booting with disable_mtrr_cleanup? > >> I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less. > > > > Here the output with v3 which is disabled by default: > > > > --($:~)-- cat /proc/mtrr > > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 > > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 > > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 > > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 > > reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 > > reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 > > > > dmesg is saying now : > > > > [ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining > > > > > > My card settings in BIOS ( that was default ) are the following : > > > > DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) > > DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT ) > > > > Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD ) > > Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) > > PEG Port -> Auto ( possible settings Auto , Disabled ) > > PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled ) > > > > Of course these settings are only possible when the card is not disabled :) > > > > I'm gonna try v4 now and enable it. Please let me know if you need more infos. > > Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ). > It takes 6 minutes to boot to : > so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is another 8M address. mtrr by BIOS is very interesting: before > > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > > reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 > > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 > > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 > > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 > > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 > > reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 after 256M chunk size got > >>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB > >>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB > >>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB > >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB > >>> [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB > >>> [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB > >>> [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC so the convering is right..., need to spare another entry for your card. or we can dumping the > >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB for extra entra... but the mtrr trimming code need to be updated instead of only using highest_pfn YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 22:03 ` Yinghai Lu @ 2008-04-28 22:56 ` Gabriel C 2008-04-28 23:23 ` Yinghai Lu 0 siblings, 1 reply; 87+ messages in thread From: Gabriel C @ 2008-04-28 22:56 UTC (permalink / raw) To: Yinghai Lu Cc: Mika Fischer, Ingo Molnar, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner Yinghai Lu wrote: > On Mon, Apr 28, 2008 at 2:19 PM, Gabriel C <nix.or.die@googlemail.com> wrote: >> Gabriel C wrote: >> > Gabriel C wrote: >> >> Yinghai Lu wrote: >> >>> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote: >> >>>> Mika Fischer wrote: >> >>>> > Hi Ingo, >> >>>> > >> >>>> > I'm having the same problem. >> >>>> > >> >>>> > Ingo Molnar schrieb: >> >>>> >> excellent. So just to make sure: this box never had proper graphics >> >>>> >> under Linux (under no previous kernel), due to the way the BIOS has set >> >>>> >> up the MTRR's, right? >> >>>> > >> >>>> > Well, not quite. X still works fine, but since the video memory is >> >>>> > overlapped by two of the existing MTRRs, X cannot add a write-combining >> >>>> > range for the video memory. That makes X rather slow especially if you >> >>>> > use DRI for Compiz etc. >> >>>> >> >>>> Well you are lucky then :) >> >>>> >> >>>> Yeah X 'worked' but it worked as slow as with vesa video driver here. >> >>> [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 >> >>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB >> >>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB >> >>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB >> >>> [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 >> >>> [ 0.000000] range: 00000000cf800000 - 00000000d0000000 >> >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB >> >>> [ 0.000000] range0: 0000000100000000 - 0000000120000000 >> >>> [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB >> >>> [ 0.000000] range: 0000000120000000 - 0000000130000000 >> >>> [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB >> >>> [ 0.000000] hole: 000000012c000000 - 0000000130000000 >> >>> [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC >> >>> >> >>> so your X server need two entries for WB? >> >>> >> >>> can you send out /proc/mtrr with booting with disable_mtrr_cleanup? >> >> I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less. >> > >> > Here the output with v3 which is disabled by default: >> > >> > --($:~)-- cat /proc/mtrr >> > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 >> > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 >> > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 >> > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 >> > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 >> > reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 >> > reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 >> > >> > dmesg is saying now : >> > >> > [ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining >> > >> > >> > My card settings in BIOS ( that was default ) are the following : >> > >> > DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) >> > DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT ) >> > >> > Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD ) >> > Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) >> > PEG Port -> Auto ( possible settings Auto , Disabled ) >> > PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled ) >> > >> > Of course these settings are only possible when the card is not disabled :) >> > >> > I'm gonna try v4 now and enable it. Please let me know if you need more infos. >> >> Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ). >> It takes 6 minutes to boot to : >> > > so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is > another 8M address. Looks like this , yes. Is using the 256MB Memory and the 8MB for Graphics Mode Select. I'm not really sure why the 8MB are needed , BIOS book doesn't tell me. I could try to disable and see what I get =) > > mtrr by BIOS is very interesting: > before >> > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 >> > reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 >> > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 >> > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 >> > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 >> > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 >> > reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 > > > after 256M chunk size got >> >>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB >> >>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB >> >>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB >> >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB >> >>> [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB >> >>> [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB >> >>> [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC > > so the convering is right..., need to spare another entry for your card. > > or we can dumping the >> >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB > for extra entra... > > but the mtrr trimming code need to be updated instead of only using highest_pfn > > YH > Gabriel ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 22:56 ` Gabriel C @ 2008-04-28 23:23 ` Yinghai Lu 2008-04-29 1:05 ` Gabriel C 0 siblings, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-28 23:23 UTC (permalink / raw) To: Gabriel C Cc: Mika Fischer, Ingo Molnar, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner [-- Attachment #1: Type: text/plain, Size: 6242 bytes --] On Mon, Apr 28, 2008 at 3:56 PM, Gabriel C <nix.or.die@googlemail.com> wrote: > > Yinghai Lu wrote: > > On Mon, Apr 28, 2008 at 2:19 PM, Gabriel C <nix.or.die@googlemail.com> wrote: > >> Gabriel C wrote: > >> > Gabriel C wrote: > >> >> Yinghai Lu wrote: > >> >>> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote: > >> >>>> Mika Fischer wrote: > >> >>>> > Hi Ingo, > >> >>>> > > >> >>>> > I'm having the same problem. > >> >>>> > > >> >>>> > Ingo Molnar schrieb: > >> >>>> >> excellent. So just to make sure: this box never had proper graphics > >> >>>> >> under Linux (under no previous kernel), due to the way the BIOS has set > >> >>>> >> up the MTRR's, right? > >> >>>> > > >> >>>> > Well, not quite. X still works fine, but since the video memory is > >> >>>> > overlapped by two of the existing MTRRs, X cannot add a write-combining > >> >>>> > range for the video memory. That makes X rather slow especially if you > >> >>>> > use DRI for Compiz etc. > >> >>>> > >> >>>> Well you are lucky then :) > >> >>>> > >> >>>> Yeah X 'worked' but it worked as slow as with vesa video driver here. > >> >>> [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 > >> >>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB > >> >>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB > >> >>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB > >> >>> [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 > >> >>> [ 0.000000] range: 00000000cf800000 - 00000000d0000000 > >> >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB > >> >>> [ 0.000000] range0: 0000000100000000 - 0000000120000000 > >> >>> [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB > >> >>> [ 0.000000] range: 0000000120000000 - 0000000130000000 > >> >>> [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB > >> >>> [ 0.000000] hole: 000000012c000000 - 0000000130000000 > >> >>> [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC > >> >>> > >> >>> so your X server need two entries for WB? > >> >>> > >> >>> can you send out /proc/mtrr with booting with disable_mtrr_cleanup? > >> >> I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less. > >> > > >> > Here the output with v3 which is disabled by default: > >> > > >> > --($:~)-- cat /proc/mtrr > >> > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 > >> > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 > >> > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > >> > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 > >> > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 > >> > reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 > >> > reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 > >> > > >> > dmesg is saying now : > >> > > >> > [ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining > >> > > >> > > >> > My card settings in BIOS ( that was default ) are the following : > >> > > >> > DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) > >> > DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT ) > >> > > >> > Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD ) > >> > Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) > >> > PEG Port -> Auto ( possible settings Auto , Disabled ) > >> > PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled ) > >> > > >> > Of course these settings are only possible when the card is not disabled :) > >> > > >> > I'm gonna try v4 now and enable it. Please let me know if you need more infos. > >> > >> Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ). > >> It takes 6 minutes to boot to : > >> > > > > so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is > > another 8M address. > > Looks like this , yes. Is using the 256MB Memory and the 8MB for Graphics Mode Select. > > I'm not really sure why the 8MB are needed , BIOS book doesn't tell me. > I could try to disable and see what I get =) > > > > > > > mtrr by BIOS is very interesting: > > before > >> > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > >> > reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 > >> > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 > >> > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 > >> > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 > >> > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 > >> > reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 > > > > > > after 256M chunk size got > >> >>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB > >> >>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB > >> >>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB > >> >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB > >> >>> [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB > >> >>> [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB > >> >>> [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC > > > > so the convering is right..., need to spare another entry for your card. > > > > or we can dumping the > >> >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB > > for extra entra... > > > > but the mtrr trimming code need to be updated instead of only using highest_pfn > > > > YH > > please try to test patch with mtrr_chunk_size= 2g; 1g, 512m, 128m. etc. only for test: i comment out the fill_var_state.. YH [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: mtrr_cleanup.patch --] [-- Type: text/x-patch; name=mtrr_cleanup.patch, Size: 15648 bytes --] [PATCH] x86: mtrr cleanup for converting continuous to discrete layout v5 some BIOS like to use continus MTRR layout, and may X driver can not add WB entries for graphical cards when 4g or more RAM installed. the patch will change MTRR to discrete. mtrr_chunk_size= could be used to have smaller continuous block to hold holes. default is 256m, could be set according to size of graphics card memory. v2: fix -1 for UC checking v3: default to disable, and need use enable_mtrr_cleanup to enable this feature skip the var state change warning. remove next_basek in range_to_mtrr() v4: correct warning mask. v5: CONFIG_MTRR_SANITIZER Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Index: linux-2.6/arch/x86/kernel/cpu/mtrr/generic.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/generic.c +++ linux-2.6/arch/x86/kernel/cpu/mtrr/generic.c @@ -158,6 +158,20 @@ get_mtrr_var_range(unsigned int index, s rdmsr(MTRRphysMask_MSR(index), vr->mask_lo, vr->mask_hi); } +/* fill the MSR pair relating to a var range */ +void fill_mtrr_var_range(unsigned int index, + u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi) +{ + struct mtrr_var_range *vr; + + vr = mtrr_state.var_ranges; + + vr[index].base_lo = base_lo; + vr[index].base_hi = base_hi; + vr[index].mask_lo = mask_lo; + vr[index].mask_hi = mask_hi; +} + static void get_fixed_ranges(mtrr_type * frs) { Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c +++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c @@ -37,6 +37,7 @@ #include <linux/smp.h> #include <linux/cpu.h> #include <linux/mutex.h> +#include <linux/sort.h> #include <asm/e820.h> #include <asm/mtrr.h> @@ -609,6 +610,366 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; +#ifdef CONFIG_MTRR_SANITIZER + +#ifdef CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT +static int enable_mtrr_cleanup __initdata = 1; +#else +static int enable_mtrr_cleanup __initdata; +#endif + +#else + +static int enable_mtrr_cleanup __initdata = -1; + +#endif + +static int __init disable_mtrr_cleanup_setup(char *str) +{ + if (enable_mtrr_cleanup != -1) + enable_mtrr_cleanup = 0; + return 0; +} +early_param("disable_mtrr_cleanup", disable_mtrr_cleanup_setup); + +static int __init enable_mtrr_cleanup_setup(char *str) +{ + if (enable_mtrr_cleanup != -1) + enable_mtrr_cleanup = 1; + return 0; +} +early_param("enble_mtrr_cleanup", enable_mtrr_cleanup_setup); + +#define RANGE_NUM 256 + +struct res_range { + size_t start; + size_t end; +}; + +static void __init subtract_range(struct res_range *range, size_t start, + size_t end) +{ + int i; + int j; + + for (j = 0; j < RANGE_NUM; j++) { + if (!range[j].end) + continue; + + if (start <= range[j].start && end >= range[j].end) { + range[j].start = 0; + range[j].end = 0; + continue; + } + + if (start <= range[j].start && end < range[j].end && range[j].start < end + 1) { + range[j].start = end + 1; + continue; + } + + + if (start > range[j].start && end >= range[j].end && range[j].end > start - 1) { + range[j].end = start - 1; + continue; + } + + if (start > range[j].start && end < range[j].end) { + /* find the new spare */ + for (i = 0; i < RANGE_NUM; i++) { + if (range[i].end == 0) + break; + } + if (i < RANGE_NUM) { + range[i].end = range[j].end; + range[i].start = end + 1; + } else { + printk(KERN_ERR "run of slot in ranges\n"); + } + range[j].end = start - 1; + continue; + } + } +} + +static int __cpuinit cmp_range(const void *x1, const void *x2) +{ + const struct res_range *r1 = x1; + const struct res_range *r2 = x2; + s64 start1, start2; + + start1 = r1->start; + start2 = r2->start; + + return start1 - start2; +} + +struct var_mtrr_state { + unsigned long range_startk, range_sizek; + unsigned long chunk_sizek; + unsigned int reg; + unsigned address_bits; +}; + +static void __init set_var_mtrr( + unsigned int reg, unsigned long basek, unsigned long sizek, + unsigned char type, unsigned address_bits) +{ + u32 base_lo, base_hi, mask_lo, mask_hi; + unsigned address_mask_high; + + if (!sizek) { +// fill_mtrr_var_range(reg, 0, 0, 0, 0); + return; + } + + address_mask_high = ((1u << (address_bits - 32u)) - 1u); + + base_hi = basek >> 22; + base_lo = basek << 10; + + if (sizek < 4*1024*1024) { + mask_hi = address_mask_high; + mask_lo = ~((sizek << 10) - 1); + } else { + mask_hi = address_mask_high & (~((sizek >> 22) - 1)); + mask_lo = 0; + } + + base_lo |= type; + mask_lo |= 0x800; +// fill_mtrr_var_range(reg, base_lo, base_hi, mask_lo, mask_hi); +} + +static unsigned int __init range_to_mtrr(unsigned int reg, + unsigned long range_startk, unsigned long range_sizek, + unsigned char type, unsigned address_bits) +{ + if (!range_sizek || (reg >= num_var_ranges)) + return reg; + + while (range_sizek) { + unsigned long max_align, align; + unsigned long sizek; + /* Compute the maximum size I can make a range */ + if (range_startk) + max_align = ffs(range_startk) - 1; + else + max_align = 32; + align = fls(range_sizek) - 1; + if (align > max_align) + align = max_align; + + sizek = 1 << align; + printk(KERN_INFO "Setting variable MTRR %d, base: %ldMB, range: %ldMB, type %s\n", + reg, range_startk >> 10, sizek >> 10, + (type == MTRR_TYPE_UNCACHABLE)?"UC": + ((type == MTRR_TYPE_WRBACK)?"WB":"Other") + ); + set_var_mtrr(reg++, range_startk, sizek, type, address_bits); + range_startk += sizek; + range_sizek -= sizek; + if (reg >= num_var_ranges) + break; + } + return reg; +} + +static void __init range_to_mtrr_with_hole(struct var_mtrr_state *state, unsigned long basek) +{ + unsigned long hole_basek, hole_sizek; + unsigned long range0_basek, range0_sizek; + unsigned long range_basek, range_sizek; + unsigned long chunk_sizek; + + hole_basek = 0; + hole_sizek = 0; + chunk_sizek = state->chunk_sizek; + range0_basek = state->range_startk; + + /* try to append some small hole */ + range0_sizek = ALIGN(state->range_sizek, chunk_sizek); + if ((range0_sizek == state->range_sizek) || + ((range0_basek + range0_sizek > basek) && basek)) { + printk(KERN_INFO "rangeX: %016lx - %016lx\n", range0_basek<<10, (range0_basek + range0_sizek)<<10); + state->reg = range_to_mtrr(state->reg, range0_basek, + range0_sizek, MTRR_TYPE_WRBACK, state->address_bits); + return; + } + + range0_sizek -= chunk_sizek; + range_basek = range0_basek + range0_sizek; + printk(KERN_INFO "range0: %016lx - %016lx\n", range0_basek<<10, (range0_basek + range0_sizek)<<10); + state->reg = range_to_mtrr(state->reg, range0_basek, + range0_sizek, MTRR_TYPE_WRBACK, state->address_bits); + + range_sizek = chunk_sizek; + if (range_sizek - (state->range_sizek - range0_sizek) < (chunk_sizek >> 1)) + hole_sizek = range_sizek - (state->range_sizek - range0_sizek); + else + range_sizek = state->range_sizek - range0_sizek; + + printk(KERN_INFO "range: %016lx - %016lx\n", range_basek<<10, (range_basek + range_sizek)<<10); + state->reg = range_to_mtrr(state->reg, range_basek, + range_sizek, MTRR_TYPE_WRBACK, state->address_bits); + if (hole_sizek) { + printk(KERN_INFO "hole: %016lx - %016lx\n", hole_basek<<10, (hole_basek + hole_sizek)<<10); + state->reg = range_to_mtrr(state->reg, hole_basek, + hole_sizek, MTRR_TYPE_UNCACHABLE, state->address_bits); + } +} + +static void __init set_var_mtrr_range(struct var_mtrr_state *state, size_t base_pfn, size_t size_pfn) +{ + unsigned long basek, sizek; + + if (state->reg >= num_var_ranges) + return; + + basek = base_pfn << (PAGE_SHIFT - 10); + sizek = size_pfn << (PAGE_SHIFT - 10); + + /* See if I can merge with the last range */ + if ((basek <= 1024) || (state->range_startk + state->range_sizek == basek)) { + unsigned long endk = basek + sizek; + state->range_sizek = endk - state->range_startk; + return; + } + /* Write the range mtrrs */ + if (state->range_sizek != 0) { + range_to_mtrr_with_hole(state, basek); + + state->range_startk = 0; + state->range_sizek = 0; + } + /* Allocate an msr */ + state->range_startk = basek; + state->range_sizek = sizek; +} + +static u64 mtrr_chunk_size __initdata = (256ULL<<20); + +static int __init parse_mtrr_chunk_size_opt(char *p) +{ + if (!p) + return -EINVAL; + mtrr_chunk_size = memparse(p, &p); + return 0; +} +early_param("mtrr_chunk_size", parse_mtrr_chunk_size_opt); + +static void __init x86_setup_var_mtrrs(struct res_range *range, int nr_range, unsigned address_bits) +{ + struct var_mtrr_state var_state; + int i; + + var_state.range_startk = 0; + var_state.range_sizek = 0; + var_state.reg = 0; + var_state.address_bits = address_bits; + var_state.chunk_sizek = mtrr_chunk_size >> 10; + + /* Write the range etc */ + for (i = 0; i < nr_range; i++) + set_var_mtrr_range(&var_state, range[i].start, range[i].end - range[i].start + 1); + + /* Write the last range */ + range_to_mtrr_with_hole(&var_state, 0); + printk(KERN_INFO "DONE variable MTRRs\n"); + /* Clear out the extra MTRR's */ + while (var_state.reg < num_var_ranges) + set_var_mtrr(var_state.reg++, 0, 0, 0, var_state.address_bits); +} + +static int __init mtrr_cleanup(unsigned address_bits) +{ + unsigned long i, base, size, def, dummy; + mtrr_type type; + struct res_range range[RANGE_NUM]; + int nr_range; + + /* extra one for all 0 */ + int num[MTRR_NUM_TYPES + 1]; + + if (!is_cpu(INTEL) || enable_mtrr_cleanup < 1) + return 0; + rdmsr(MTRRdefType_MSR, def, dummy); + def &= 0xff; + if (def != MTRR_TYPE_UNCACHABLE) + return 0; + + /* check entries number */ + memset(num, 0, sizeof(num)); + for (i = 0; i < num_var_ranges; i++) { + mtrr_if->get(i, &base, &size, &type); + if (type >= MTRR_NUM_TYPES) + continue; + if (!size) + type = MTRR_NUM_TYPES; + num[type]++; + } + + /* check if we got UC entries */ + if (!num[MTRR_TYPE_UNCACHABLE]) + return 0; + + /* check if we only had WB and UC */ + if (num[MTRR_TYPE_WRBACK] + num[MTRR_TYPE_UNCACHABLE] != + num_var_ranges - num[MTRR_NUM_TYPES]) + return 0; + + /* + * get WB ranges at first + * assume BIOS don't give us overlapping WB entries + * or add add_range? + */ + memset(range, 0, sizeof(range)); + nr_range = 0; + for (i = 0; i < num_var_ranges; i++) { + mtrr_if->get(i, &base, &size, &type); + if (type != MTRR_TYPE_WRBACK) + continue; + range[nr_range].start = base; + range[nr_range].end = base + size - 1; + nr_range++; + } + printk(KERN_INFO "After WB checking\n"); + for (i = 0; i < nr_range; i++) + printk(KERN_INFO "MTRR MAP PFN: %016lx - %016lx\n", range[i].start, range[i].end + 1); + + /* take out UC ranges */ + for (i = 0; i < num_var_ranges; i++) { + mtrr_if->get(i, &base, &size, &type); + if (type != MTRR_TYPE_UNCACHABLE) + continue; + if (!size) + continue; + subtract_range(range, base, base + size - 1); + } + /* get new range num */ + nr_range = 0; + for (i = 0; i < RANGE_NUM; i++) { + if (!range[i].end) + continue; + nr_range++; + } + printk(KERN_INFO "After UC checking\n"); + for (i = 0; i < nr_range; i++) + printk(KERN_INFO "MTRR MAP PFN: %016lx - %016lx\n", range[i].start, range[i].end + 1); + + /* sort the ranges */ + sort(range, nr_range, sizeof(struct res_range), cmp_range, NULL); + printk(KERN_INFO "After sorting\n"); + for (i = 0; i < nr_range; i++) + printk(KERN_INFO "MTRR MAP PFN: %016lx - %016lx\n", range[i].start, range[i].end + 1); + + /* convert ranges to var ranges state */ + x86_setup_var_mtrrs(range, nr_range, address_bits); + + return 1; + +} + static int disable_mtrr_trim; static int __init disable_mtrr_trim_setup(char *str) @@ -729,18 +1090,21 @@ int __init mtrr_trim_uncached_memory(uns */ void __init mtrr_bp_init(void) { + u32 phys_addr; init_ifs(); + phys_addr = 32; + if (cpu_has_mtrr) { mtrr_if = &generic_mtrr_ops; size_or_mask = 0xff000000; /* 36 bits */ size_and_mask = 0x00f00000; + phys_addr = 36; /* This is an AMD specific MSR, but we assume(hope?) that Intel will implement it to when they extend the address bus of the Xeon. */ if (cpuid_eax(0x80000000) >= 0x80000008) { - u32 phys_addr; phys_addr = cpuid_eax(0x80000008) & 0xff; /* CPUID workaround for Intel 0F33/0F34 CPU */ if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && @@ -758,6 +1122,7 @@ void __init mtrr_bp_init(void) don't support PAE */ size_or_mask = 0xfff00000; /* 32 bits */ size_and_mask = 0; + phys_addr = 32; } } else { switch (boot_cpu_data.x86_vendor) { @@ -791,8 +1156,13 @@ void __init mtrr_bp_init(void) if (mtrr_if) { set_num_var_ranges(); init_table(); - if (use_intel()) + if (use_intel()) { get_mtrr_state(); + + if (mtrr_cleanup(phys_addr)) + mtrr_if->set_all(); + + } } } @@ -829,9 +1199,10 @@ static int __init mtrr_init_finialize(vo { if (!mtrr_if) return 0; - if (use_intel()) - mtrr_state_warn(); - else { + if (use_intel()) { + if (enable_mtrr_cleanup < 1) + mtrr_state_warn(); + } else { /* The CPUs haven't MTRR and seem to not support SMP. They have * specific drivers, we use a tricky method to support * suspend/resume for them. Index: linux-2.6/arch/x86/kernel/cpu/mtrr/mtrr.h =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/mtrr.h +++ linux-2.6/arch/x86/kernel/cpu/mtrr/mtrr.h @@ -81,6 +81,8 @@ void set_mtrr_done(struct set_mtrr_conte void set_mtrr_cache_disable(struct set_mtrr_context *ctxt); void set_mtrr_prepare_save(struct set_mtrr_context *ctxt); +void fill_mtrr_var_range(unsigned int index, + u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi); void get_mtrr_state(void); extern void set_mtrr_ops(struct mtrr_ops * ops); Index: linux-2.6/Documentation/kernel-parameters.txt =================================================================== --- linux-2.6.orig/Documentation/kernel-parameters.txt +++ linux-2.6/Documentation/kernel-parameters.txt @@ -595,6 +595,16 @@ and is between 256 and 4096 characters. See drivers/char/README.epca and Documentation/digiepca.txt. + disable_mtrr_cleanup [X86] + enable_mtrr_cleanup [X86] + The kernel tries to adjust MTRR layout from continuous + to discrete, to make X server driver able to add WB + entry later. This parameter enables/disables that. + + mtrr_chunk_size=nn[KMG] [X86] + used for mtrr cleanup. It is largest continous chunk + that could hold holes aka. UC entries. + disable_mtrr_trim [X86, Intel and AMD only] By default the kernel will trim any uncacheable memory out of your available memory pool based on Index: linux-2.6/arch/x86/Kconfig =================================================================== --- linux-2.6.orig/arch/x86/Kconfig +++ linux-2.6/arch/x86/Kconfig @@ -1035,6 +1035,32 @@ config MTRR See <file:Documentation/mtrr.txt> for more information. +config MTRR_SANITIZER + def_bool y + prompt "MTRR cleanup support" + depends on MTRR + help + Convert MTRR layout from continuous to discrete, so some X driver + could add WB entries. + + Say N here if you see bootup problems (boot crash, boot hang, + spontaneous reboots). + + Could be disabled with disable_mtrr_cleanup. Also mtrr_chunk_size + could be used to send largest mtrr entry size for continuous block + to hold holes (aka. UC entries) + + If unsure, say Y. + +config MTRR_SANITIZER_ENABLE_DEFAULT + def_bool y + prompt "Enable MTRR cleanup by default" + depends on MTRR_SANITIZER + help + Enable mtrr cleanup by default + + If unsure, say Y. + config X86_PAT bool prompt "x86 PAT support" ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 23:23 ` Yinghai Lu @ 2008-04-29 1:05 ` Gabriel C 2008-04-29 2:41 ` Yinghai Lu 0 siblings, 1 reply; 87+ messages in thread From: Gabriel C @ 2008-04-29 1:05 UTC (permalink / raw) To: Yinghai Lu Cc: Mika Fischer, Ingo Molnar, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner Yinghai Lu wrote: > On Mon, Apr 28, 2008 at 3:56 PM, Gabriel C <nix.or.die@googlemail.com> wrote: >> Yinghai Lu wrote: >> > On Mon, Apr 28, 2008 at 2:19 PM, Gabriel C <nix.or.die@googlemail.com> wrote: >> >> Gabriel C wrote: >> >> > Gabriel C wrote: >> >> >> Yinghai Lu wrote: >> >> >>> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote: >> >> >>>> Mika Fischer wrote: >> >> >>>> > Hi Ingo, >> >> >>>> > >> >> >>>> > I'm having the same problem. >> >> >>>> > >> >> >>>> > Ingo Molnar schrieb: >> >> >>>> >> excellent. So just to make sure: this box never had proper graphics >> >> >>>> >> under Linux (under no previous kernel), due to the way the BIOS has set >> >> >>>> >> up the MTRR's, right? >> >> >>>> > >> >> >>>> > Well, not quite. X still works fine, but since the video memory is >> >> >>>> > overlapped by two of the existing MTRRs, X cannot add a write-combining >> >> >>>> > range for the video memory. That makes X rather slow especially if you >> >> >>>> > use DRI for Compiz etc. >> >> >>>> >> >> >>>> Well you are lucky then :) >> >> >>>> >> >> >>>> Yeah X 'worked' but it worked as slow as with vesa video driver here. >> >> >>> [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 >> >> >>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB >> >> >>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB >> >> >>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB >> >> >>> [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 >> >> >>> [ 0.000000] range: 00000000cf800000 - 00000000d0000000 >> >> >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB >> >> >>> [ 0.000000] range0: 0000000100000000 - 0000000120000000 >> >> >>> [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB >> >> >>> [ 0.000000] range: 0000000120000000 - 0000000130000000 >> >> >>> [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB >> >> >>> [ 0.000000] hole: 000000012c000000 - 0000000130000000 >> >> >>> [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC >> >> >>> >> >> >>> so your X server need two entries for WB? >> >> >>> >> >> >>> can you send out /proc/mtrr with booting with disable_mtrr_cleanup? >> >> >> I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less. >> >> > >> >> > Here the output with v3 which is disabled by default: >> >> > >> >> > --($:~)-- cat /proc/mtrr >> >> > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 >> >> > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 >> >> > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 >> >> > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 >> >> > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 >> >> > reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 >> >> > reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 >> >> > >> >> > dmesg is saying now : >> >> > >> >> > [ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining >> >> > >> >> > >> >> > My card settings in BIOS ( that was default ) are the following : >> >> > >> >> > DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) >> >> > DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT ) >> >> > >> >> > Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD ) >> >> > Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) >> >> > PEG Port -> Auto ( possible settings Auto , Disabled ) >> >> > PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled ) >> >> > >> >> > Of course these settings are only possible when the card is not disabled :) >> >> > >> >> > I'm gonna try v4 now and enable it. Please let me know if you need more infos. >> >> >> >> Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ). >> >> It takes 6 minutes to boot to : >> >> >> > >> > so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is >> > another 8M address. >> >> Looks like this , yes. Is using the 256MB Memory and the 8MB for Graphics Mode Select. >> >> I'm not really sure why the 8MB are needed , BIOS book doesn't tell me. >> I could try to disable and see what I get =) >> >> >> >> > >> > mtrr by BIOS is very interesting: >> > before >> >> > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 >> >> > reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 >> >> > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 >> >> > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 >> >> > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 >> >> > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 >> >> > reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 >> > >> > >> > after 256M chunk size got >> >> >>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB >> >> >>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB >> >> >>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB >> >> >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB >> >> >>> [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB >> >> >>> [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB >> >> >>> [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC >> > >> > so the convering is right..., need to spare another entry for your card. >> > >> > or we can dumping the >> >> >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB >> > for extra entra... >> > >> > but the mtrr trimming code need to be updated instead of only using highest_pfn >> > >> > YH >> > > > please try to test patch with mtrr_chunk_size= 2g; 1g, 512m, 128m. etc. > only for test: i comment out the fill_var_state.. There are the dmesg's , down to 2m and without chunk_size : http://frugalware.org/~crazy/mtrr/mtrr/ > > YH > Gabriel ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-29 1:05 ` Gabriel C @ 2008-04-29 2:41 ` Yinghai Lu 2008-04-29 10:34 ` Ingo Molnar 0 siblings, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-29 2:41 UTC (permalink / raw) To: Gabriel C Cc: Mika Fischer, Ingo Molnar, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner [-- Attachment #1: Type: text/plain, Size: 7044 bytes --] On Mon, Apr 28, 2008 at 6:05 PM, Gabriel C <nix.or.die@googlemail.com> wrote: > > Yinghai Lu wrote: > > On Mon, Apr 28, 2008 at 3:56 PM, Gabriel C <nix.or.die@googlemail.com> wrote: > >> Yinghai Lu wrote: > >> > On Mon, Apr 28, 2008 at 2:19 PM, Gabriel C <nix.or.die@googlemail.com> wrote: > >> >> Gabriel C wrote: > >> >> > Gabriel C wrote: > >> >> >> Yinghai Lu wrote: > >> >> >>> On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote: > >> >> >>>> Mika Fischer wrote: > >> >> >>>> > Hi Ingo, > >> >> >>>> > > >> >> >>>> > I'm having the same problem. > >> >> >>>> > > >> >> >>>> > Ingo Molnar schrieb: > >> >> >>>> >> excellent. So just to make sure: this box never had proper graphics > >> >> >>>> >> under Linux (under no previous kernel), due to the way the BIOS has set > >> >> >>>> >> up the MTRR's, right? > >> >> >>>> > > >> >> >>>> > Well, not quite. X still works fine, but since the video memory is > >> >> >>>> > overlapped by two of the existing MTRRs, X cannot add a write-combining > >> >> >>>> > range for the video memory. That makes X rather slow especially if you > >> >> >>>> > use DRI for Compiz etc. > >> >> >>>> > >> >> >>>> Well you are lucky then :) > >> >> >>>> > >> >> >>>> Yeah X 'worked' but it worked as slow as with vesa video driver here. > >> >> >>> [ 0.000000] rangeX: 0000000000000000 - 00000000d0000000 > >> >> >>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB > >> >> >>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB > >> >> >>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB > >> >> >>> [ 0.000000] range0: 00000000cf800000 - 00000000cf800000 > >> >> >>> [ 0.000000] range: 00000000cf800000 - 00000000d0000000 > >> >> >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB > >> >> >>> [ 0.000000] range0: 0000000100000000 - 0000000120000000 > >> >> >>> [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB > >> >> >>> [ 0.000000] range: 0000000120000000 - 0000000130000000 > >> >> >>> [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB > >> >> >>> [ 0.000000] hole: 000000012c000000 - 0000000130000000 > >> >> >>> [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC > >> >> >>> > >> >> >>> so your X server need two entries for WB? > >> >> >>> > >> >> >>> can you send out /proc/mtrr with booting with disable_mtrr_cleanup? > >> >> >> I can just not right now , cannot reboot the box yet. In about 1h or so , maybe less. > >> >> > > >> >> > Here the output with v3 which is disabled by default: > >> >> > > >> >> > --($:~)-- cat /proc/mtrr > >> >> > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 > >> >> > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 > >> >> > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > >> >> > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 > >> >> > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 > >> >> > reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 > >> >> > reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 > >> >> > > >> >> > dmesg is saying now : > >> >> > > >> >> > [ 22.764595] mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining > >> >> > > >> >> > > >> >> > My card settings in BIOS ( that was default ) are the following : > >> >> > > >> >> > DVMT Mode -> DVMT Mode ( possible setting DVMT Mode or Fixed Mode ) > >> >> > DVMT / Memory -> 256MB ( possible settings 128/256 MB or Maximum DVMT ) > >> >> > > >> >> > Initiate Graphics Adapter -> PEG/PCI ( possible settings IGD , PCI/IGD , PCI/PEG , PEG/IGD ) > >> >> > Internal Graphics Mode Select -> Enabled,8MB ( possible settings Enabled,8MB , Enabled,1MB maybe Disabled I forgot to look) > >> >> > PEG Port -> Auto ( possible settings Auto , Disabled ) > >> >> > PEG Port Force x1 -> Disabled ( possible settings Enabled , Disabled ) > >> >> > > >> >> > Of course these settings are only possible when the card is not disabled :) > >> >> > > >> >> > I'm gonna try v4 now and enable it. Please let me know if you need more infos. > >> >> > >> >> Hmm v4 doesn't work anymore here ( I've tested with all possible settings in BIOS ). > >> >> It takes 6 minutes to boot to : > >> >> > >> > > >> > so you card is using 256M and 8M? 0xd0000000-0xe0000000, where is > >> > another 8M address. > >> > >> Looks like this , yes. Is using the 256MB Memory and the 8MB for Graphics Mode Select. > >> > >> I'm not really sure why the 8MB are needed , BIOS book doesn't tell me. > >> I could try to disable and see what I get =) > >> > >> > >> > >> > > >> > mtrr by BIOS is very interesting: > >> > before > >> >> > reg02: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > >> >> > reg06: base=0xcf600000 (3318MB), size= 2MB: uncachable, count=1 > >> >> > reg00: base=0xd0000000 (3328MB), size= 256MB: uncachable, count=1 > >> >> > reg01: base=0xe0000000 (3584MB), size= 512MB: uncachable, count=1 > >> >> > reg03: base=0x100000000 (4096MB), size= 512MB: write-back, count=1 > >> >> > reg04: base=0x120000000 (4608MB), size= 128MB: write-back, count=1 > >> >> > reg05: base=0x128000000 (4736MB), size= 64MB: write-back, count=1 > >> > > >> > > >> > after 256M chunk size got > >> >> >>> [ 0.000000] Setting variable MTRR 0, base: 0MB, range: 2048MB, type WB > >> >> >>> [ 0.000000] Setting variable MTRR 1, base: 2048MB, range: 1024MB, type WB > >> >> >>> [ 0.000000] Setting variable MTRR 2, base: 3072MB, range: 256MB, type WB > >> >> >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB > >> >> >>> [ 0.000000] Setting variable MTRR 4, base: 4096MB, range: 512MB, type WB > >> >> >>> [ 0.000000] Setting variable MTRR 5, base: 4608MB, range: 256MB, type WB > >> >> >>> [ 0.000000] Setting variable MTRR 6, base: 4800MB, range: 64MB, type UC > >> > > >> > so the convering is right..., need to spare another entry for your card. > >> > > >> > or we can dumping the > >> >> >>> [ 0.000000] Setting variable MTRR 3, base: 3320MB, range: 8MB, type WB > >> > for extra entra... > >> > > >> > but the mtrr trimming code need to be updated instead of only using highest_pfn > >> > > >> > YH > >> > > > > > please try to test patch with mtrr_chunk_size= 2g; 1g, 512m, 128m. etc. > > only for test: i comment out the fill_var_state.. > > There are the dmesg's , down to 2m and without chunk_size : > > http://frugalware.org/~crazy/mtrr/mtrr/ please check this one v6 test. please only check =2g, 1g, and 512m, 256m, 128m, 64m. Thanks Yinghai Lu [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #2: mtrr_cleanup_v6.patch --] [-- Type: text/x-patch; name=mtrr_cleanup_v6.patch, Size: 15910 bytes --] [PATCH] x86: mtrr cleanup for converting continuous to discrete layout v6 some BIOS like to use continus MTRR layout, and may X driver can not add WB entries for graphical cards when 4g or more RAM installed. the patch will change MTRR to discrete. mtrr_chunk_size= could be used to have smaller continuous block to hold holes. default is 256m, could be set according to size of graphics card memory. v2: fix -1 for UC checking v3: default to disable, and need use enable_mtrr_cleanup to enable this feature skip the var state change warning. remove next_basek in range_to_mtrr() v4: correct warning mask. v5: CONFIG_MTRR_SANITIZER v6: 1g, 2g, 512 aligment with extra hole Signed-off-by: Yinghai Lu <yhlu.kernel@gmail.com> Index: linux-2.6/arch/x86/kernel/cpu/mtrr/generic.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/generic.c +++ linux-2.6/arch/x86/kernel/cpu/mtrr/generic.c @@ -158,6 +158,20 @@ get_mtrr_var_range(unsigned int index, s rdmsr(MTRRphysMask_MSR(index), vr->mask_lo, vr->mask_hi); } +/* fill the MSR pair relating to a var range */ +void fill_mtrr_var_range(unsigned int index, + u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi) +{ + struct mtrr_var_range *vr; + + vr = mtrr_state.var_ranges; + + vr[index].base_lo = base_lo; + vr[index].base_hi = base_hi; + vr[index].mask_lo = mask_lo; + vr[index].mask_hi = mask_hi; +} + static void get_fixed_ranges(mtrr_type * frs) { Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c +++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c @@ -37,6 +37,7 @@ #include <linux/smp.h> #include <linux/cpu.h> #include <linux/mutex.h> +#include <linux/sort.h> #include <asm/e820.h> #include <asm/mtrr.h> @@ -609,6 +610,375 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; +#ifdef CONFIG_MTRR_SANITIZER + +#ifdef CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT +static int enable_mtrr_cleanup __initdata = 1; +#else +static int enable_mtrr_cleanup __initdata; +#endif + +#else + +static int enable_mtrr_cleanup __initdata = -1; + +#endif + +static int __init disable_mtrr_cleanup_setup(char *str) +{ + if (enable_mtrr_cleanup != -1) + enable_mtrr_cleanup = 0; + return 0; +} +early_param("disable_mtrr_cleanup", disable_mtrr_cleanup_setup); + +static int __init enable_mtrr_cleanup_setup(char *str) +{ + if (enable_mtrr_cleanup != -1) + enable_mtrr_cleanup = 1; + return 0; +} +early_param("enble_mtrr_cleanup", enable_mtrr_cleanup_setup); + +#define RANGE_NUM 256 + +struct res_range { + size_t start; + size_t end; +}; + +static void __init subtract_range(struct res_range *range, size_t start, + size_t end) +{ + int i; + int j; + + for (j = 0; j < RANGE_NUM; j++) { + if (!range[j].end) + continue; + + if (start <= range[j].start && end >= range[j].end) { + range[j].start = 0; + range[j].end = 0; + continue; + } + + if (start <= range[j].start && end < range[j].end && range[j].start < end + 1) { + range[j].start = end + 1; + continue; + } + + + if (start > range[j].start && end >= range[j].end && range[j].end > start - 1) { + range[j].end = start - 1; + continue; + } + + if (start > range[j].start && end < range[j].end) { + /* find the new spare */ + for (i = 0; i < RANGE_NUM; i++) { + if (range[i].end == 0) + break; + } + if (i < RANGE_NUM) { + range[i].end = range[j].end; + range[i].start = end + 1; + } else { + printk(KERN_ERR "run of slot in ranges\n"); + } + range[j].end = start - 1; + continue; + } + } +} + +static int __cpuinit cmp_range(const void *x1, const void *x2) +{ + const struct res_range *r1 = x1; + const struct res_range *r2 = x2; + s64 start1, start2; + + start1 = r1->start; + start2 = r2->start; + + return start1 - start2; +} + +struct var_mtrr_state { + unsigned long range_startk, range_sizek; + unsigned long chunk_sizek; + unsigned int reg; + unsigned address_bits; +}; + +static void __init set_var_mtrr( + unsigned int reg, unsigned long basek, unsigned long sizek, + unsigned char type, unsigned address_bits) +{ + u32 base_lo, base_hi, mask_lo, mask_hi; + unsigned address_mask_high; + + if (!sizek) { +// fill_mtrr_var_range(reg, 0, 0, 0, 0); + return; + } + + address_mask_high = ((1u << (address_bits - 32u)) - 1u); + + base_hi = basek >> 22; + base_lo = basek << 10; + + if (sizek < 4*1024*1024) { + mask_hi = address_mask_high; + mask_lo = ~((sizek << 10) - 1); + } else { + mask_hi = address_mask_high & (~((sizek >> 22) - 1)); + mask_lo = 0; + } + + base_lo |= type; + mask_lo |= 0x800; +// fill_mtrr_var_range(reg, base_lo, base_hi, mask_lo, mask_hi); +} + +static unsigned int __init range_to_mtrr(unsigned int reg, + unsigned long range_startk, unsigned long range_sizek, + unsigned char type, unsigned address_bits) +{ + if (!range_sizek || (reg >= num_var_ranges)) + return reg; + + while (range_sizek) { + unsigned long max_align, align; + unsigned long sizek; + /* Compute the maximum size I can make a range */ + if (range_startk) + max_align = ffs(range_startk) - 1; + else + max_align = 32; + align = fls(range_sizek) - 1; + if (align > max_align) + align = max_align; + + sizek = 1 << align; + printk(KERN_INFO "Setting variable MTRR %d, base: %ldMB, range: %ldMB, type %s\n", + reg, range_startk >> 10, sizek >> 10, + (type == MTRR_TYPE_UNCACHABLE)?"UC": + ((type == MTRR_TYPE_WRBACK)?"WB":"Other") + ); + set_var_mtrr(reg++, range_startk, sizek, type, address_bits); + range_startk += sizek; + range_sizek -= sizek; + if (reg >= num_var_ranges) + break; + } + return reg; +} + +static void __init range_to_mtrr_with_hole(struct var_mtrr_state *state, unsigned long basek) +{ + unsigned long hole_basek, hole_sizek; + unsigned long range0_basek, range0_sizek; + unsigned long range_basek, range_sizek; + unsigned long chunk_sizek; + + hole_basek = 0; + hole_sizek = 0; + chunk_sizek = state->chunk_sizek; + range0_basek = state->range_startk; + + /* try to append some small hole */ + range0_sizek = ALIGN(state->range_sizek, chunk_sizek); + if ((range0_sizek == state->range_sizek) || + ((range0_basek + range0_sizek - chunk_sizek > basek) && basek)) { + printk(KERN_INFO "rangeX: %016lx - %016lx\n", range0_basek<<10, (range0_basek + state->range_sizek)<<10); + state->reg = range_to_mtrr(state->reg, range0_basek, + state->range_sizek, MTRR_TYPE_WRBACK, state->address_bits); + return; + } + + + range0_sizek -= chunk_sizek; + range_basek = range0_basek + range0_sizek; + printk(KERN_INFO "range0: %016lx - %016lx\n", range0_basek<<10, (range0_basek + range0_sizek)<<10); + state->reg = range_to_mtrr(state->reg, range0_basek, + range0_sizek, MTRR_TYPE_WRBACK, state->address_bits); + + range_sizek = chunk_sizek; + if (range_sizek - (state->range_sizek - range0_sizek) < (chunk_sizek >> 1)) + hole_sizek = range_sizek - (state->range_sizek - range0_sizek); + else + range_sizek = state->range_sizek - range0_sizek; + + printk(KERN_INFO "range: %016lx - %016lx\n", range_basek<<10, (range_basek + range_sizek)<<10); + state->reg = range_to_mtrr(state->reg, range_basek, + range_sizek, MTRR_TYPE_WRBACK, state->address_bits); + if (hole_sizek) { + printk(KERN_INFO "hole: %016lx - %016lx\n", hole_basek<<10, (hole_basek + hole_sizek)<<10); + state->reg = range_to_mtrr(state->reg, hole_basek, + hole_sizek, MTRR_TYPE_UNCACHABLE, state->address_bits); + } +} + +static void __init set_var_mtrr_range(struct var_mtrr_state *state, size_t base_pfn, size_t size_pfn) +{ + unsigned long basek, sizek; + + if (state->reg >= num_var_ranges) + return; + + basek = base_pfn << (PAGE_SHIFT - 10); + sizek = size_pfn << (PAGE_SHIFT - 10); + + /* See if I can merge with the last range */ + if ((basek <= 1024) || (state->range_startk + state->range_sizek == basek)) { + unsigned long endk = basek + sizek; + state->range_sizek = endk - state->range_startk; + return; + } + /* Write the range mtrrs */ + if (state->range_sizek != 0) { + range_to_mtrr_with_hole(state, basek); + + state->range_startk = 0; + state->range_sizek = 0; + } + /* Allocate an msr */ + state->range_startk = basek; + state->range_sizek = sizek; +} + +static u64 mtrr_chunk_size __initdata = (256ULL<<20); + +static int __init parse_mtrr_chunk_size_opt(char *p) +{ + if (!p) + return -EINVAL; + mtrr_chunk_size = memparse(p, &p); + return 0; +} +early_param("mtrr_chunk_size", parse_mtrr_chunk_size_opt); + +static void __init x86_setup_var_mtrrs(struct res_range *range, int nr_range, unsigned address_bits) +{ + struct var_mtrr_state var_state; + int i; + + var_state.range_startk = 0; + var_state.range_sizek = 0; + var_state.reg = 0; + var_state.address_bits = address_bits; + var_state.chunk_sizek = mtrr_chunk_size >> 10; + + /* Write the range etc */ + for (i = 0; i < nr_range; i++) + set_var_mtrr_range(&var_state, range[i].start, range[i].end - range[i].start + 1); + + /* Write the last range */ + range_to_mtrr_with_hole(&var_state, 0); + printk(KERN_INFO "DONE variable MTRRs\n"); + /* Clear out the extra MTRR's */ + while (var_state.reg < num_var_ranges) + set_var_mtrr(var_state.reg++, 0, 0, 0, var_state.address_bits); +} + +static int __init x86_get_mtrr_mem_range(struct res_range *range, int nr_range) +{ + unsigned long i, base, size; + mtrr_type type; + /* + * get WB ranges at first + * assume BIOS don't give us overlapping WB entries + * or add add_range? + */ + for (i = 0; i < num_var_ranges; i++) { + mtrr_if->get(i, &base, &size, &type); + if (type != MTRR_TYPE_WRBACK) + continue; + range[nr_range].start = base; + range[nr_range].end = base + size - 1; + nr_range++; + } + printk(KERN_INFO "After WB checking\n"); + for (i = 0; i < nr_range; i++) + printk(KERN_INFO "MTRR MAP PFN: %016lx - %016lx\n", range[i].start, range[i].end + 1); + + /* take out UC ranges */ + for (i = 0; i < num_var_ranges; i++) { + mtrr_if->get(i, &base, &size, &type); + if (type != MTRR_TYPE_UNCACHABLE) + continue; + if (!size) + continue; + subtract_range(range, base, base + size - 1); + } + /* get new range num */ + nr_range = 0; + for (i = 0; i < RANGE_NUM; i++) { + if (!range[i].end) + continue; + nr_range++; + } + printk(KERN_INFO "After UC checking\n"); + for (i = 0; i < nr_range; i++) + printk(KERN_INFO "MTRR MAP PFN: %016lx - %016lx\n", range[i].start, range[i].end + 1); + + /* sort the ranges */ + sort(range, nr_range, sizeof(struct res_range), cmp_range, NULL); + printk(KERN_INFO "After sorting\n"); + for (i = 0; i < nr_range; i++) + printk(KERN_INFO "MTRR MAP PFN: %016lx - %016lx\n", range[i].start, range[i].end + 1); + + return nr_range; +} + +static int __init mtrr_cleanup(unsigned address_bits) +{ + unsigned long i, base, size, def, dummy; + mtrr_type type; + struct res_range range[RANGE_NUM]; + int nr_range; + + /* extra one for all 0 */ + int num[MTRR_NUM_TYPES + 1]; + + if (!is_cpu(INTEL) || enable_mtrr_cleanup < 1) + return 0; + rdmsr(MTRRdefType_MSR, def, dummy); + def &= 0xff; + if (def != MTRR_TYPE_UNCACHABLE) + return 0; + + /* check entries number */ + memset(num, 0, sizeof(num)); + for (i = 0; i < num_var_ranges; i++) { + mtrr_if->get(i, &base, &size, &type); + if (type >= MTRR_NUM_TYPES) + continue; + if (!size) + type = MTRR_NUM_TYPES; + num[type]++; + } + + /* check if we got UC entries */ + if (!num[MTRR_TYPE_UNCACHABLE]) + return 0; + + /* check if we only had WB and UC */ + if (num[MTRR_TYPE_WRBACK] + num[MTRR_TYPE_UNCACHABLE] != + num_var_ranges - num[MTRR_NUM_TYPES]) + return 0; + + memset(range, 0, sizeof(range)); + nr_range = x86_get_mtrr_mem_range(range, 0); + + /* convert ranges to var ranges state */ + x86_setup_var_mtrrs(range, nr_range, address_bits); + + return 1; + +} + static int disable_mtrr_trim; static int __init disable_mtrr_trim_setup(char *str) @@ -729,18 +1099,21 @@ int __init mtrr_trim_uncached_memory(uns */ void __init mtrr_bp_init(void) { + u32 phys_addr; init_ifs(); + phys_addr = 32; + if (cpu_has_mtrr) { mtrr_if = &generic_mtrr_ops; size_or_mask = 0xff000000; /* 36 bits */ size_and_mask = 0x00f00000; + phys_addr = 36; /* This is an AMD specific MSR, but we assume(hope?) that Intel will implement it to when they extend the address bus of the Xeon. */ if (cpuid_eax(0x80000000) >= 0x80000008) { - u32 phys_addr; phys_addr = cpuid_eax(0x80000008) & 0xff; /* CPUID workaround for Intel 0F33/0F34 CPU */ if (boot_cpu_data.x86_vendor == X86_VENDOR_INTEL && @@ -758,6 +1131,7 @@ void __init mtrr_bp_init(void) don't support PAE */ size_or_mask = 0xfff00000; /* 32 bits */ size_and_mask = 0; + phys_addr = 32; } } else { switch (boot_cpu_data.x86_vendor) { @@ -791,8 +1165,13 @@ void __init mtrr_bp_init(void) if (mtrr_if) { set_num_var_ranges(); init_table(); - if (use_intel()) + if (use_intel()) { get_mtrr_state(); + + if (mtrr_cleanup(phys_addr)) + mtrr_if->set_all(); + + } } } @@ -829,9 +1208,10 @@ static int __init mtrr_init_finialize(vo { if (!mtrr_if) return 0; - if (use_intel()) - mtrr_state_warn(); - else { + if (use_intel()) { + if (enable_mtrr_cleanup < 1) + mtrr_state_warn(); + } else { /* The CPUs haven't MTRR and seem to not support SMP. They have * specific drivers, we use a tricky method to support * suspend/resume for them. Index: linux-2.6/arch/x86/kernel/cpu/mtrr/mtrr.h =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/mtrr.h +++ linux-2.6/arch/x86/kernel/cpu/mtrr/mtrr.h @@ -81,6 +81,8 @@ void set_mtrr_done(struct set_mtrr_conte void set_mtrr_cache_disable(struct set_mtrr_context *ctxt); void set_mtrr_prepare_save(struct set_mtrr_context *ctxt); +void fill_mtrr_var_range(unsigned int index, + u32 base_lo, u32 base_hi, u32 mask_lo, u32 mask_hi); void get_mtrr_state(void); extern void set_mtrr_ops(struct mtrr_ops * ops); Index: linux-2.6/Documentation/kernel-parameters.txt =================================================================== --- linux-2.6.orig/Documentation/kernel-parameters.txt +++ linux-2.6/Documentation/kernel-parameters.txt @@ -595,6 +595,16 @@ and is between 256 and 4096 characters. See drivers/char/README.epca and Documentation/digiepca.txt. + disable_mtrr_cleanup [X86] + enable_mtrr_cleanup [X86] + The kernel tries to adjust MTRR layout from continuous + to discrete, to make X server driver able to add WB + entry later. This parameter enables/disables that. + + mtrr_chunk_size=nn[KMG] [X86] + used for mtrr cleanup. It is largest continous chunk + that could hold holes aka. UC entries. + disable_mtrr_trim [X86, Intel and AMD only] By default the kernel will trim any uncacheable memory out of your available memory pool based on Index: linux-2.6/arch/x86/Kconfig =================================================================== --- linux-2.6.orig/arch/x86/Kconfig +++ linux-2.6/arch/x86/Kconfig @@ -1035,6 +1035,32 @@ config MTRR See <file:Documentation/mtrr.txt> for more information. +config MTRR_SANITIZER + def_bool y + prompt "MTRR cleanup support" + depends on MTRR + help + Convert MTRR layout from continuous to discrete, so some X driver + could add WB entries. + + Say N here if you see bootup problems (boot crash, boot hang, + spontaneous reboots). + + Could be disabled with disable_mtrr_cleanup. Also mtrr_chunk_size + could be used to send largest mtrr entry size for continuous block + to hold holes (aka. UC entries) + + If unsure, say Y. + +config MTRR_SANITIZER_ENABLE_DEFAULT + def_bool y + prompt "Enable MTRR cleanup by default" + depends on MTRR_SANITIZER + help + Enable mtrr cleanup by default + + If unsure, say Y. + config X86_PAT bool prompt "x86 PAT support" ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-29 2:41 ` Yinghai Lu @ 2008-04-29 10:34 ` Ingo Molnar 2008-04-29 10:42 ` Yinghai Lu 0 siblings, 1 reply; 87+ messages in thread From: Ingo Molnar @ 2008-04-29 10:34 UTC (permalink / raw) To: Yinghai Lu Cc: Gabriel C, Mika Fischer, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner * Yinghai Lu <yhlu.kernel@gmail.com> wrote: > v2: fix -1 for UC checking > v3: default to disable, and need use enable_mtrr_cleanup to enable this feature > skip the var state change warning. > remove next_basek in range_to_mtrr() > v4: correct warning mask. > v5: CONFIG_MTRR_SANITIZER > v6: 1g, 2g, 512 aligment with extra hole thanks Yinghai, i picked up v6. Ingo ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-29 10:34 ` Ingo Molnar @ 2008-04-29 10:42 ` Yinghai Lu 0 siblings, 0 replies; 87+ messages in thread From: Yinghai Lu @ 2008-04-29 10:42 UTC (permalink / raw) To: Ingo Molnar Cc: Gabriel C, Mika Fischer, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner On Tue, Apr 29, 2008 at 3:34 AM, Ingo Molnar <mingo@elte.hu> wrote: > > * Yinghai Lu <yhlu.kernel@gmail.com> wrote: > > > v2: fix -1 for UC checking > > v3: default to disable, and need use enable_mtrr_cleanup to enable this feature > > skip the var state change warning. > > remove next_basek in range_to_mtrr() > > v4: correct warning mask. > > v5: CONFIG_MTRR_SANITIZER > > v6: 1g, 2g, 512 aligment with extra hole > > thanks Yinghai, i picked up v6. please use v8 instead. will send it out in minutes. also it need [PATCH 2/2] x86: fix trimming e820 with MTRR holes. it could check range is not coverred below 4g when 8g ram installed. YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 14:24 ` Gabriel C 2008-04-28 19:06 ` Yinghai Lu @ 2008-04-28 19:08 ` Yinghai Lu 2008-04-28 19:46 ` Gabriel C 1 sibling, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-28 19:08 UTC (permalink / raw) To: Gabriel C Cc: Mika Fischer, Ingo Molnar, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote: > Mika Fischer wrote: > > Hi Ingo, > > > > I'm having the same problem. > > > > Ingo Molnar schrieb: > >> excellent. So just to make sure: this box never had proper graphics > >> under Linux (under no previous kernel), due to the way the BIOS has set > >> up the MTRR's, right? > > > > Well, not quite. X still works fine, but since the video memory is > > overlapped by two of the existing MTRRs, X cannot add a write-combining > > range for the video memory. That makes X rather slow especially if you > > use DRI for Compiz etc. > > Well you are lucky then :) > > Yeah X 'worked' but it worked as slow as with vesa video driver here. > > Also starting something like supertuxkart made it crash or I got a black screen :( > > The only game I managed to start ( without X to crash ) without that patch was supertux but is was slow as hell. > However I'm not a gamer but I need X to work right. > or can you change graphics card memory in BIOS to some big like 256M instead of 64M? YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 19:08 ` Yinghai Lu @ 2008-04-28 19:46 ` Gabriel C 0 siblings, 0 replies; 87+ messages in thread From: Gabriel C @ 2008-04-28 19:46 UTC (permalink / raw) To: Yinghai Lu Cc: Mika Fischer, Ingo Molnar, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, balajirrao, Andi Kleen, Thomas Gleixner Yinghai Lu wrote: > On Mon, Apr 28, 2008 at 7:24 AM, Gabriel C <nix.or.die@googlemail.com> wrote: >> Mika Fischer wrote: >> > Hi Ingo, >> > >> > I'm having the same problem. >> > >> > Ingo Molnar schrieb: >> >> excellent. So just to make sure: this box never had proper graphics >> >> under Linux (under no previous kernel), due to the way the BIOS has set >> >> up the MTRR's, right? >> > >> > Well, not quite. X still works fine, but since the video memory is >> > overlapped by two of the existing MTRRs, X cannot add a write-combining >> > range for the video memory. That makes X rather slow especially if you >> > use DRI for Compiz etc. >> >> Well you are lucky then :) >> >> Yeah X 'worked' but it worked as slow as with vesa video driver here. >> >> Also starting something like supertuxkart made it crash or I got a black screen :( >> >> The only game I managed to start ( without X to crash ) without that patch was supertux but is was slow as hell. >> However I'm not a gamer but I need X to work right. >> > or can you change graphics card memory in BIOS to some big like 256M > instead of 64M? > It is set to 256M , I cannot even set it to 64MB in BIOS. I have options for 128/256 MB only and I think I can change the mode to fixed. > YH > Gabriel ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 13:53 ` Ingo Molnar 2008-04-28 14:11 ` Mika Fischer @ 2008-04-28 14:15 ` Gabriel C 2008-04-28 16:09 ` Jesse Barnes 2 siblings, 0 replies; 87+ messages in thread From: Gabriel C @ 2008-04-28 14:15 UTC (permalink / raw) To: Ingo Molnar Cc: Yinghai Lu, Andrew Morton, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao, Andi Kleen, Thomas Gleixner Ingo Molnar wrote: > * Gabriel C <nix.or.die@googlemail.com> wrote: > >>> please try v2 version >>> >>> http://lkml.org/lkml/2008/4/28/115 >> Box still won't boot with mtrr_chunk_size=1g but without it is perfect >> :)) Thx for your work. I've quick tested some games and 3d things , >> all are working with this patch really nice. > > excellent. So just to make sure: this box never had proper graphics > under Linux (under no previous kernel), due to the way the BIOS has set > up the MTRR's, right? The box is really new so far I tested 2.6.24* 2.6.25 , linux-next , current git from which no one worked. And yes is right graphics under Linux didn't worked right without patch from http://lkml.org/lkml/2008/4/28/115. > > so fixing up the MTRRs during bootup, no matter how dangerous in theory, > is pretty much the best option to get your system to work fine under > Linux, with that specific Xorg version? Yes. I run : xorg-server 1.4.0.90-5 ( it has all fixes from server-1.4-branch ) mesa 7.0.2-2 xf86-video-intel 2.3.0-1 Probably I have to replace 2x2G with 2x1G to get it work without this patch but it is something I don't really want to do =) Also I'm not sure whatever this is an BIOS bug ? I could contact ASUS people if someone tells me what is wrong with the BIOS. > > i think we should still try to make this a non-default option because > modern Xorg should not have any need to touch MTRRs. Perhaps a .config > dependent on CONFIG_DANGEROUS ;-) Hmm 1.4.0.90 is not that old , is it ? > > Ingo > Gabriel ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 13:53 ` Ingo Molnar 2008-04-28 14:11 ` Mika Fischer 2008-04-28 14:15 ` Gabriel C @ 2008-04-28 16:09 ` Jesse Barnes 2008-04-28 16:31 ` Mika Fischer 2008-04-29 10:37 ` Ingo Molnar 2 siblings, 2 replies; 87+ messages in thread From: Jesse Barnes @ 2008-04-28 16:09 UTC (permalink / raw) To: Ingo Molnar Cc: Gabriel C, Yinghai Lu, Andrew Morton, H. Peter Anvin, LKML, Mika Fischer, balajirrao, Andi Kleen, Thomas Gleixner On Monday, April 28, 2008 6:53 am Ingo Molnar wrote: > i think we should still try to make this a non-default option because > modern Xorg should not have any need to touch MTRRs. Perhaps a .config > dependent on CONFIG_DANGEROUS ;-) Well, not quite... we're still waiting on some way of getting WC semantics for sysfs PCI files. Suresh tells me something like that is queued up, but until that hits the mainline X will still need to bang the MTRRs to get decent performance. Jesse ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 16:09 ` Jesse Barnes @ 2008-04-28 16:31 ` Mika Fischer 2008-04-28 16:55 ` Jesse Barnes 2008-04-29 10:37 ` Ingo Molnar 1 sibling, 1 reply; 87+ messages in thread From: Mika Fischer @ 2008-04-28 16:31 UTC (permalink / raw) To: Jesse Barnes Cc: Ingo Molnar, Gabriel C, Yinghai Lu, Andrew Morton, H. Peter Anvin, LKML, balajirrao, Andi Kleen, Thomas Gleixner Jesse Barnes schrieb: > On Monday, April 28, 2008 6:53 am Ingo Molnar wrote: >> i think we should still try to make this a non-default option because >> modern Xorg should not have any need to touch MTRRs. Perhaps a .config >> dependent on CONFIG_DANGEROUS ;-) > > Well, not quite... we're still waiting on some way of getting WC semantics for > sysfs PCI files. Suresh tells me something like that is queued up, but until > that hits the mainline X will still need to bang the MTRRs to get decent > performance. Do you happen to know if this new sysfs-way will work correctly in the case where the MTRRs explicitly say that the video-memory is uncachable? Regards, Mika ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 16:31 ` Mika Fischer @ 2008-04-28 16:55 ` Jesse Barnes 0 siblings, 0 replies; 87+ messages in thread From: Jesse Barnes @ 2008-04-28 16:55 UTC (permalink / raw) To: Mika Fischer Cc: Ingo Molnar, Gabriel C, Yinghai Lu, Andrew Morton, H. Peter Anvin, LKML, balajirrao, Andi Kleen, Thomas Gleixner On Monday, April 28, 2008 9:31 am Mika Fischer wrote: > Jesse Barnes schrieb: > > On Monday, April 28, 2008 6:53 am Ingo Molnar wrote: > >> i think we should still try to make this a non-default option because > >> modern Xorg should not have any need to touch MTRRs. Perhaps a .config > >> dependent on CONFIG_DANGEROUS ;-) > > > > Well, not quite... we're still waiting on some way of getting WC > > semantics for sysfs PCI files. Suresh tells me something like that is > > queued up, but until that hits the mainline X will still need to bang the > > MTRRs to get decent performance. > > Do you happen to know if this new sysfs-way will work correctly in the > case where the MTRRs explicitly say that the video-memory is uncachable? It should, since we'll be using PAT to set the cache control in the sysfs case. Jesse ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 16:09 ` Jesse Barnes 2008-04-28 16:31 ` Mika Fischer @ 2008-04-29 10:37 ` Ingo Molnar 2008-04-29 12:40 ` Andrew Morton 2008-04-29 15:52 ` Jesse Barnes 1 sibling, 2 replies; 87+ messages in thread From: Ingo Molnar @ 2008-04-29 10:37 UTC (permalink / raw) To: Jesse Barnes Cc: Gabriel C, Yinghai Lu, Andrew Morton, H. Peter Anvin, LKML, Mika Fischer, balajirrao, Andi Kleen, Thomas Gleixner * Jesse Barnes <jesse.barnes@intel.com> wrote: > > i think we should still try to make this a non-default option > > because modern Xorg should not have any need to touch MTRRs. Perhaps > > a .config dependent on CONFIG_DANGEROUS ;-) > > Well, not quite... we're still waiting on some way of getting WC > semantics for sysfs PCI files. Suresh tells me something like that is > queued up, but until that hits the mainline X will still need to bang > the MTRRs to get decent performance. yes, the patch below is queued up for an eventual v2.6.26 merge. If it looks fine to you, could you please ack it so that we can send it to Linus? I'd like to do this after some pending PAT fixes are upstream. Ingo ----------------> Subject: x86, PAT: export resource_wc in pci sysfs From: venkatesh.pallipadi@intel.com Date: Tue, 18 Mar 2008 17:00:22 -0700 For the ranges with IORESOURCE_PREFETCH, export a new resource_wc interface in pci /sysfs along with resource (which is uncached). Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Signed-off-by: Ingo Molnar <mingo@elte.hu> --- Documentation/filesystems/sysfs-pci.txt | 1 drivers/pci/pci-sysfs.c | 82 +++++++++++++++++++++++--------- include/linux/pci.h | 1 3 files changed, 63 insertions(+), 21 deletions(-) Index: linux-x86.q/Documentation/filesystems/sysfs-pci.txt =================================================================== --- linux-x86.q.orig/Documentation/filesystems/sysfs-pci.txt +++ linux-x86.q/Documentation/filesystems/sysfs-pci.txt @@ -36,6 +36,7 @@ files, each with their own function. local_cpus nearby CPU mask (cpumask, ro) resource PCI resource host addresses (ascii, ro) resource0..N PCI resource N, if present (binary, mmap) + resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap) rom PCI ROM resource, if present (binary, ro) subsystem_device PCI subsystem device (ascii, ro) subsystem_vendor PCI subsystem vendor (ascii, ro) Index: linux-x86.q/drivers/pci/pci-sysfs.c =================================================================== --- linux-x86.q.orig/drivers/pci/pci-sysfs.c +++ linux-x86.q/drivers/pci/pci-sysfs.c @@ -489,13 +489,14 @@ pci_mmap_legacy_mem(struct kobject *kobj * @kobj: kobject for mapping * @attr: struct bin_attribute for the file being mapped * @vma: struct vm_area_struct passed into the mmap + * @write_combine: 1 for write_combine mapping * * Use the regular PCI mapping routines to map a PCI resource into userspace. * FIXME: write combining? maybe automatic for prefetchable regions? */ static int pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr, - struct vm_area_struct *vma) + struct vm_area_struct *vma, int write_combine) { struct pci_dev *pdev = to_pci_dev(container_of(kobj, struct device, kobj)); @@ -518,7 +519,21 @@ pci_mmap_resource(struct kobject *kobj, vma->vm_pgoff += start >> PAGE_SHIFT; mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io; - return pci_mmap_page_range(pdev, vma, mmap_type, 0); + return pci_mmap_page_range(pdev, vma, mmap_type, write_combine); +} + +static int +pci_mmap_resource_uc(struct kobject *kobj, struct bin_attribute *attr, + struct vm_area_struct *vma) +{ + return pci_mmap_resource(kobj, attr, vma, 0); +} + +static int +pci_mmap_resource_wc(struct kobject *kobj, struct bin_attribute *attr, + struct vm_area_struct *vma) +{ + return pci_mmap_resource(kobj, attr, vma, 1); } /** @@ -541,9 +556,46 @@ pci_remove_resource_files(struct pci_dev sysfs_remove_bin_file(&pdev->dev.kobj, res_attr); kfree(res_attr); } + + res_attr = pdev->res_attr_wc[i]; + if (res_attr) { + sysfs_remove_bin_file(&pdev->dev.kobj, res_attr); + kfree(res_attr); + } } } +static int pci_create_attr(struct pci_dev *pdev, int num, int write_combine) +{ + /* allocate attribute structure, piggyback attribute name */ + int name_len = write_combine ? 13 : 10; + struct bin_attribute *res_attr; + int retval; + + res_attr = kzalloc(sizeof(*res_attr) + name_len, GFP_ATOMIC); + if (res_attr) { + char *res_attr_name = (char *)(res_attr + 1); + + if (write_combine) { + pdev->res_attr_wc[num] = res_attr; + sprintf(res_attr_name, "resource%d_wc", num); + res_attr->mmap = pci_mmap_resource_wc; + } else { + pdev->res_attr[num] = res_attr; + sprintf(res_attr_name, "resource%d", num); + res_attr->mmap = pci_mmap_resource_uc; + } + res_attr->attr.name = res_attr_name; + res_attr->attr.mode = S_IRUSR | S_IWUSR; + res_attr->size = pci_resource_len(pdev, num); + res_attr->private = &pdev->resource[num]; + retval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr); + } else + retval = -ENOMEM; + + return retval; +} + /** * pci_create_resource_files - create resource files in sysfs for @dev * @dev: dev in question @@ -557,31 +609,19 @@ static int pci_create_resource_files(str /* Expose the PCI resources from this device as files */ for (i = 0; i < PCI_ROM_RESOURCE; i++) { - struct bin_attribute *res_attr; /* skip empty resources */ if (!pci_resource_len(pdev, i)) continue; - /* allocate attribute structure, piggyback attribute name */ - res_attr = kzalloc(sizeof(*res_attr) + 10, GFP_ATOMIC); - if (res_attr) { - char *res_attr_name = (char *)(res_attr + 1); + retval = pci_create_attr(pdev, i, 0); + /* for prefetchable resources, create a WC mappable file */ + if (!retval && pdev->resource[i].flags & IORESOURCE_PREFETCH) + retval = pci_create_attr(pdev, i, 1); - pdev->res_attr[i] = res_attr; - sprintf(res_attr_name, "resource%d", i); - res_attr->attr.name = res_attr_name; - res_attr->attr.mode = S_IRUSR | S_IWUSR; - res_attr->size = pci_resource_len(pdev, i); - res_attr->mmap = pci_mmap_resource; - res_attr->private = &pdev->resource[i]; - retval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr); - if (retval) { - pci_remove_resource_files(pdev); - return retval; - } - } else { - return -ENOMEM; + if (retval) { + pci_remove_resource_files(pdev); + return retval; } } return 0; Index: linux-x86.q/include/linux/pci.h =================================================================== --- linux-x86.q.orig/include/linux/pci.h +++ linux-x86.q/include/linux/pci.h @@ -205,6 +205,7 @@ struct pci_dev { struct bin_attribute *rom_attr; /* attribute descriptor for sysfs ROM entry */ int rom_attr_enabled; /* has display of the rom attribute been enabled? */ struct bin_attribute *res_attr[DEVICE_COUNT_RESOURCE]; /* sysfs file for resources */ + struct bin_attribute *res_attr_wc[DEVICE_COUNT_RESOURCE]; /* sysfs file for WC mapping of resources */ #ifdef CONFIG_PCI_MSI struct list_head msi_list; #endif ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-29 10:37 ` Ingo Molnar @ 2008-04-29 12:40 ` Andrew Morton 2008-04-29 15:52 ` Jesse Barnes 1 sibling, 0 replies; 87+ messages in thread From: Andrew Morton @ 2008-04-29 12:40 UTC (permalink / raw) To: Ingo Molnar Cc: Jesse Barnes, Gabriel C, Yinghai Lu, H. Peter Anvin, LKML, Mika Fischer, balajirrao, Andi Kleen, Thomas Gleixner On Tue, 29 Apr 2008 12:37:41 +0200 Ingo Molnar <mingo@elte.hu> wrote: > +static int pci_create_attr(struct pci_dev *pdev, int num, int write_combine) > +{ > + /* allocate attribute structure, piggyback attribute name */ > + int name_len = write_combine ? 13 : 10; > + struct bin_attribute *res_attr; > + int retval; > + > + res_attr = kzalloc(sizeof(*res_attr) + name_len, GFP_ATOMIC); That (retained from current code) GFP_ATOMIC cannot be necessary. > + if (res_attr) { > + char *res_attr_name = (char *)(res_attr + 1); > + > + if (write_combine) { > + pdev->res_attr_wc[num] = res_attr; > + sprintf(res_attr_name, "resource%d_wc", num); > + res_attr->mmap = pci_mmap_resource_wc; > + } else { > + pdev->res_attr[num] = res_attr; > + sprintf(res_attr_name, "resource%d", num); > + res_attr->mmap = pci_mmap_resource_uc; > + } > + res_attr->attr.name = res_attr_name; > + res_attr->attr.mode = S_IRUSR | S_IWUSR; > + res_attr->size = pci_resource_len(pdev, num); > + res_attr->private = &pdev->resource[num]; > + retval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr); Because of this. > + } else > + retval = -ENOMEM; > + > + return retval; > +} ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-29 10:37 ` Ingo Molnar 2008-04-29 12:40 ` Andrew Morton @ 2008-04-29 15:52 ` Jesse Barnes 2008-04-29 22:03 ` [patch] PCI: export resource_wc in pci sysfs Ingo Molnar 1 sibling, 1 reply; 87+ messages in thread From: Jesse Barnes @ 2008-04-29 15:52 UTC (permalink / raw) To: Ingo Molnar Cc: Gabriel C, Yinghai Lu, Andrew Morton, H. Peter Anvin, LKML, Mika Fischer, balajirrao, Andi Kleen, Thomas Gleixner On Tuesday, April 29, 2008 3:37 am Ingo Molnar wrote: > * Jesse Barnes <jesse.barnes@intel.com> wrote: > > > i think we should still try to make this a non-default option > > > because modern Xorg should not have any need to touch MTRRs. Perhaps > > > a .config dependent on CONFIG_DANGEROUS ;-) > > > > Well, not quite... we're still waiting on some way of getting WC > > semantics for sysfs PCI files. Suresh tells me something like that is > > queued up, but until that hits the mainline X will still need to bang > > the MTRRs to get decent performance. > > yes, the patch below is queued up for an eventual v2.6.26 merge. If it > looks fine to you, could you please ack it so that we can send it to > Linus? I'd like to do this after some pending PAT fixes are upstream. > > Ingo > > ----------------> > Subject: x86, PAT: export resource_wc in pci sysfs > From: venkatesh.pallipadi@intel.com > Date: Tue, 18 Mar 2008 17:00:22 -0700 > > For the ranges with IORESOURCE_PREFETCH, export a new resource_wc interface > in pci /sysfs along with resource (which is uncached). > > Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> > Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> > Signed-off-by: Ingo Molnar <mingo@elte.hu> I really would have preferred a new mmap flag for this like ia64 used to have, but Suresh and Venki tell me that a flag doesn't map very well to what some architectures support, so I suppose a new file is the way to go. Should work fine for X's needs. Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Thanks, Jesse ^ permalink raw reply [flat|nested] 87+ messages in thread
* [patch] PCI: export resource_wc in pci sysfs 2008-04-29 15:52 ` Jesse Barnes @ 2008-04-29 22:03 ` Ingo Molnar 2008-04-29 22:24 ` Andrew Morton 0 siblings, 1 reply; 87+ messages in thread From: Ingo Molnar @ 2008-04-29 22:03 UTC (permalink / raw) To: Jesse Barnes, Linus Torvalds Cc: Gabriel C, Yinghai Lu, Andrew Morton, H. Peter Anvin, LKML, Mika Fischer, balajirrao, Andi Kleen, Thomas Gleixner * Jesse Barnes <jesse.barnes@intel.com> wrote: > I really would have preferred a new mmap flag for this like ia64 used > to have, but Suresh and Venki tell me that a flag doesn't map very > well to what some architectures support, so I suppose a new file is > the way to go. Should work fine for X's needs. > > Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> thanks! Linus, please apply the patch below. Ingo ------------------> Subject: PCI: export resource_wc in pci sysfs From: venkatesh.pallipadi@intel.com Date: Tue, 18 Mar 2008 17:00:22 -0700 For the ranges with IORESOURCE_PREFETCH, export a new resource_wc interface in pci /sysfs along with resource (which is uncached). Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com> Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com> Acked-by: Jesse Barnes <jbarnes@virtuousgeek.org> Signed-off-by: Ingo Molnar <mingo@elte.hu> --- Documentation/filesystems/sysfs-pci.txt | 1 drivers/pci/pci-sysfs.c | 82 +++++++++++++++++++++++--------- include/linux/pci.h | 1 3 files changed, 63 insertions(+), 21 deletions(-) Index: linux-x86.q/Documentation/filesystems/sysfs-pci.txt =================================================================== --- linux-x86.q.orig/Documentation/filesystems/sysfs-pci.txt +++ linux-x86.q/Documentation/filesystems/sysfs-pci.txt @@ -36,6 +36,7 @@ files, each with their own function. local_cpus nearby CPU mask (cpumask, ro) resource PCI resource host addresses (ascii, ro) resource0..N PCI resource N, if present (binary, mmap) + resource0_wc..N_wc PCI WC map resource N, if prefetchable (binary, mmap) rom PCI ROM resource, if present (binary, ro) subsystem_device PCI subsystem device (ascii, ro) subsystem_vendor PCI subsystem vendor (ascii, ro) Index: linux-x86.q/drivers/pci/pci-sysfs.c =================================================================== --- linux-x86.q.orig/drivers/pci/pci-sysfs.c +++ linux-x86.q/drivers/pci/pci-sysfs.c @@ -489,13 +489,14 @@ pci_mmap_legacy_mem(struct kobject *kobj * @kobj: kobject for mapping * @attr: struct bin_attribute for the file being mapped * @vma: struct vm_area_struct passed into the mmap + * @write_combine: 1 for write_combine mapping * * Use the regular PCI mapping routines to map a PCI resource into userspace. * FIXME: write combining? maybe automatic for prefetchable regions? */ static int pci_mmap_resource(struct kobject *kobj, struct bin_attribute *attr, - struct vm_area_struct *vma) + struct vm_area_struct *vma, int write_combine) { struct pci_dev *pdev = to_pci_dev(container_of(kobj, struct device, kobj)); @@ -518,7 +519,21 @@ pci_mmap_resource(struct kobject *kobj, vma->vm_pgoff += start >> PAGE_SHIFT; mmap_type = res->flags & IORESOURCE_MEM ? pci_mmap_mem : pci_mmap_io; - return pci_mmap_page_range(pdev, vma, mmap_type, 0); + return pci_mmap_page_range(pdev, vma, mmap_type, write_combine); +} + +static int +pci_mmap_resource_uc(struct kobject *kobj, struct bin_attribute *attr, + struct vm_area_struct *vma) +{ + return pci_mmap_resource(kobj, attr, vma, 0); +} + +static int +pci_mmap_resource_wc(struct kobject *kobj, struct bin_attribute *attr, + struct vm_area_struct *vma) +{ + return pci_mmap_resource(kobj, attr, vma, 1); } /** @@ -541,9 +556,46 @@ pci_remove_resource_files(struct pci_dev sysfs_remove_bin_file(&pdev->dev.kobj, res_attr); kfree(res_attr); } + + res_attr = pdev->res_attr_wc[i]; + if (res_attr) { + sysfs_remove_bin_file(&pdev->dev.kobj, res_attr); + kfree(res_attr); + } } } +static int pci_create_attr(struct pci_dev *pdev, int num, int write_combine) +{ + /* allocate attribute structure, piggyback attribute name */ + int name_len = write_combine ? 13 : 10; + struct bin_attribute *res_attr; + int retval; + + res_attr = kzalloc(sizeof(*res_attr) + name_len, GFP_ATOMIC); + if (res_attr) { + char *res_attr_name = (char *)(res_attr + 1); + + if (write_combine) { + pdev->res_attr_wc[num] = res_attr; + sprintf(res_attr_name, "resource%d_wc", num); + res_attr->mmap = pci_mmap_resource_wc; + } else { + pdev->res_attr[num] = res_attr; + sprintf(res_attr_name, "resource%d", num); + res_attr->mmap = pci_mmap_resource_uc; + } + res_attr->attr.name = res_attr_name; + res_attr->attr.mode = S_IRUSR | S_IWUSR; + res_attr->size = pci_resource_len(pdev, num); + res_attr->private = &pdev->resource[num]; + retval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr); + } else + retval = -ENOMEM; + + return retval; +} + /** * pci_create_resource_files - create resource files in sysfs for @dev * @dev: dev in question @@ -557,31 +609,19 @@ static int pci_create_resource_files(str /* Expose the PCI resources from this device as files */ for (i = 0; i < PCI_ROM_RESOURCE; i++) { - struct bin_attribute *res_attr; /* skip empty resources */ if (!pci_resource_len(pdev, i)) continue; - /* allocate attribute structure, piggyback attribute name */ - res_attr = kzalloc(sizeof(*res_attr) + 10, GFP_ATOMIC); - if (res_attr) { - char *res_attr_name = (char *)(res_attr + 1); + retval = pci_create_attr(pdev, i, 0); + /* for prefetchable resources, create a WC mappable file */ + if (!retval && pdev->resource[i].flags & IORESOURCE_PREFETCH) + retval = pci_create_attr(pdev, i, 1); - pdev->res_attr[i] = res_attr; - sprintf(res_attr_name, "resource%d", i); - res_attr->attr.name = res_attr_name; - res_attr->attr.mode = S_IRUSR | S_IWUSR; - res_attr->size = pci_resource_len(pdev, i); - res_attr->mmap = pci_mmap_resource; - res_attr->private = &pdev->resource[i]; - retval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr); - if (retval) { - pci_remove_resource_files(pdev); - return retval; - } - } else { - return -ENOMEM; + if (retval) { + pci_remove_resource_files(pdev); + return retval; } } return 0; Index: linux-x86.q/include/linux/pci.h =================================================================== --- linux-x86.q.orig/include/linux/pci.h +++ linux-x86.q/include/linux/pci.h @@ -205,6 +205,7 @@ struct pci_dev { struct bin_attribute *rom_attr; /* attribute descriptor for sysfs ROM entry */ int rom_attr_enabled; /* has display of the rom attribute been enabled? */ struct bin_attribute *res_attr[DEVICE_COUNT_RESOURCE]; /* sysfs file for resources */ + struct bin_attribute *res_attr_wc[DEVICE_COUNT_RESOURCE]; /* sysfs file for WC mapping of resources */ #ifdef CONFIG_PCI_MSI struct list_head msi_list; #endif ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [patch] PCI: export resource_wc in pci sysfs 2008-04-29 22:03 ` [patch] PCI: export resource_wc in pci sysfs Ingo Molnar @ 2008-04-29 22:24 ` Andrew Morton 0 siblings, 0 replies; 87+ messages in thread From: Andrew Morton @ 2008-04-29 22:24 UTC (permalink / raw) To: Ingo Molnar Cc: jesse.barnes, torvalds, nix.or.die, yhlu.kernel, hpa, linux-kernel, mika.fischer, balajirrao, andi, tglx On Wed, 30 Apr 2008 00:03:46 +0200 Ingo Molnar <mingo@elte.hu> wrote: > +static int pci_create_attr(struct pci_dev *pdev, int num, int write_combine) > +{ > + /* allocate attribute structure, piggyback attribute name */ > + int name_len = write_combine ? 13 : 10; > + struct bin_attribute *res_attr; > + int retval; > + > + res_attr = kzalloc(sizeof(*res_attr) + name_len, GFP_ATOMIC); > + if (res_attr) { > + char *res_attr_name = (char *)(res_attr + 1); > + > + if (write_combine) { > + pdev->res_attr_wc[num] = res_attr; > + sprintf(res_attr_name, "resource%d_wc", num); > + res_attr->mmap = pci_mmap_resource_wc; > + } else { > + pdev->res_attr[num] = res_attr; > + sprintf(res_attr_name, "resource%d", num); > + res_attr->mmap = pci_mmap_resource_uc; > + } > + res_attr->attr.name = res_attr_name; > + res_attr->attr.mode = S_IRUSR | S_IWUSR; > + res_attr->size = pci_resource_len(pdev, num); > + res_attr->private = &pdev->resource[num]; > + retval = sysfs_create_bin_file(&pdev->dev.kobj, res_attr); > + } else > + retval = -ENOMEM; > + > + return retval; > +} That GFP_ATOMIC should be switched to GFP_KERNEL. Do we reeeeeeeely need to pull this tack-the-string-onto-the-end-of-the-struct stunt? If we didn't do that, this code could then be taught about kasprintf() and things like that "? 13 : 10" could be thankfully laid to rest. ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-26 10:56 ` Andrew Morton 2008-04-26 12:56 ` Gabriel C @ 2008-04-27 0:57 ` Yinghai Lu 2008-04-27 8:21 ` Mika Fischer 2008-04-27 1:22 ` Yinghai Lu 2008-04-28 6:50 ` Yinghai Lu 3 siblings, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-27 0:57 UTC (permalink / raw) To: Andrew Morton Cc: Ingo Molnar, Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao On Sat, Apr 26, 2008 at 3:56 AM, Andrew Morton <akpm@linux-foundation.org> wrote: > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: > > > [PATCH] x86_32: trim memory by updating e820 v3 > > > > when mtrr is not covering all e820 table, need to trim the ram, need to update e820 > > > > reuse some code for x86_64 > > > > here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early > > > > need Justine to test with his special system with bug bios. > > > > Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> > > Speaking of mtrr and e820.... > > Could someone please take a peek at > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ? > > For some reason we seem to have turned this: > > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) > [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) > [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) > [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) > [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) > [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) > [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) > [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) > [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) > [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) > [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) > > into this: > > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > > which screws up the X server's attempt to map the video memory at > 0xd0000000. can you check if you can set up MTRR mapping in BIOS from Continuous to Discrete? YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-27 0:57 ` [PATCH] x86_32: trim memory by updating e820 v3 Yinghai Lu @ 2008-04-27 8:21 ` Mika Fischer 0 siblings, 0 replies; 87+ messages in thread From: Mika Fischer @ 2008-04-27 8:21 UTC (permalink / raw) To: Yinghai Lu Cc: Andrew Morton, Ingo Molnar, Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, balajirrao Yinghai Lu schrieb: > On Sat, Apr 26, 2008 at 3:56 AM, Andrew Morton > <akpm@linux-foundation.org> wrote: >> Could someone please take a peek at >> http://bugzilla.kernel.org/show_bug.cgi?id=10508 ? > > can you check if you can set up MTRR mapping in BIOS from Continuous > to Discrete? Unfortunately my BIOS offers no advanced settings at all. The only thing I can change is the size of the video memory. But changing this has no effect on the MTRRs. Regards, Mika ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-26 10:56 ` Andrew Morton 2008-04-26 12:56 ` Gabriel C 2008-04-27 0:57 ` [PATCH] x86_32: trim memory by updating e820 v3 Yinghai Lu @ 2008-04-27 1:22 ` Yinghai Lu 2008-04-27 8:29 ` Mika Fischer 2008-04-28 6:50 ` Yinghai Lu 3 siblings, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-27 1:22 UTC (permalink / raw) To: Andrew Morton Cc: Ingo Molnar, Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao On Sat, Apr 26, 2008 at 3:56 AM, Andrew Morton <akpm@linux-foundation.org> wrote: > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: > > > [PATCH] x86_32: trim memory by updating e820 v3 > > > > when mtrr is not covering all e820 table, need to trim the ram, need to update e820 > > > > reuse some code for x86_64 > > > > here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early > > > > need Justine to test with his special system with bug bios. > > > > Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> > > Speaking of mtrr and e820.... > > Could someone please take a peek at > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ? > > For some reason we seem to have turned this: > > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) > [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) > [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) > [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) > [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) > [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) > [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) > [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) > [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) > [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) > [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) > > into this: > > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > > which screws up the X server's attempt to map the video memory at > 0xd0000000. > the BIOS should have set memhole to 2048MB or 2560M instead of 1033MB good mtrr should > reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1 > reg01: base=0x100000000 (4096MB), size=2048MB: write-back, count=1 or > reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1 > reg01: base=0x80000000 (2048MB), size=512MB: write-back, count=1 > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 > reg03: base=0x140000000 (4096MB), size=512MB: write-back, count=1 so please talk to your HW esp CPU vendor to fix the BIOS problem. AMD Rev F and Quadcore should get > reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1 or > reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1 > reg01: base=0x80000000 (2048MB), size=512MB: write-back, count=1 because [4G, TOM2) is WB by default. YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-27 1:22 ` Yinghai Lu @ 2008-04-27 8:29 ` Mika Fischer 0 siblings, 0 replies; 87+ messages in thread From: Mika Fischer @ 2008-04-27 8:29 UTC (permalink / raw) To: Yinghai Lu Cc: Andrew Morton, Ingo Molnar, Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, balajirrao Yinghai Lu wrote: >> reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 >> reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 >> reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 >> reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 >> reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 >> >> which screws up the X server's attempt to map the video memory at >> 0xd0000000. > > the BIOS should have set memhole to 2048MB or 2560M instead of 1033MB > > good mtrr should > >> reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1 >> reg01: base=0x100000000 (4096MB), size=2048MB: write-back, count=1 > > or > >> reg00: base=0x00000000 (0MB), size=2048MB: write-back, count=1 >> reg01: base=0x80000000 (2048MB), size=512MB: write-back, count=1 >> reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 >> reg03: base=0x140000000 (4096MB), size=512MB: write-back, count=1 > > so please talk to your HW esp CPU vendor to fix the BIOS problem. This is a Core 2 Duo CPU, so my CPU vendor is Intel. I assume that the relevant people are already reading this, no? I'm not sure what I'm supposed to do? Write an Email to Intel support, referencing this thread? Doesn't anyone here already know the right people at Intel who could actually do something about this. I think that would be more useful since I doubt an email to Intel support would reach those people... Regards, Mika ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-26 10:56 ` Andrew Morton ` (2 preceding siblings ...) 2008-04-27 1:22 ` Yinghai Lu @ 2008-04-28 6:50 ` Yinghai Lu 2008-04-28 8:38 ` Mika Fischer 3 siblings, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-28 6:50 UTC (permalink / raw) To: Andrew Morton Cc: Ingo Molnar, Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, Mika Fischer, balajirrao On Sat, Apr 26, 2008 at 3:56 AM, Andrew Morton <akpm@linux-foundation.org> wrote: > On Tue, 22 Jan 2008 16:23:20 -0800 Yinghai Lu <Yinghai.Lu@Sun.COM> wrote: > > > [PATCH] x86_32: trim memory by updating e820 v3 > > > > when mtrr is not covering all e820 table, need to trim the ram, need to update e820 > > > > reuse some code for x86_64 > > > > here need to add early_get_cap and use it in early_cpu_detect, and move mtrr_bp_init early > > > > need Justine to test with his special system with bug bios. > > > > Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> > > Speaking of mtrr and e820.... > > Could someone please take a peek at > http://bugzilla.kernel.org/show_bug.cgi?id=10508 ? > > For some reason we seem to have turned this: > > [ 0.000000] BIOS-e820: 0000000000000000 - 000000000009f800 (usable) > [ 0.000000] BIOS-e820: 000000000009f800 - 00000000000a0000 (reserved) > [ 0.000000] BIOS-e820: 00000000000dc000 - 0000000000100000 (reserved) > [ 0.000000] BIOS-e820: 0000000000100000 - 00000000bf6d0000 (usable) > [ 0.000000] BIOS-e820: 00000000bf6d0000 - 00000000bf6e3000 (ACPI NVS) > [ 0.000000] BIOS-e820: 00000000bf6e3000 - 00000000c0000000 (reserved) > [ 0.000000] BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved) > [ 0.000000] BIOS-e820: 00000000fec00000 - 00000000fec10000 (reserved) > [ 0.000000] BIOS-e820: 00000000fed00000 - 00000000fed00400 (reserved) > [ 0.000000] BIOS-e820: 00000000fed14000 - 00000000fed1a000 (reserved) > [ 0.000000] BIOS-e820: 00000000fed1c000 - 00000000fed90000 (reserved) > [ 0.000000] BIOS-e820: 00000000fee00000 - 00000000fee01000 (reserved) > [ 0.000000] BIOS-e820: 00000000ff000000 - 0000000100000000 (reserved) > [ 0.000000] BIOS-e820: 0000000100000000 - 0000000140000000 (usable) > > into this: > > reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 > reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 > reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > > which screws up the X server's attempt to map the video memory at > 0xd0000000. please try the patch at http://lkml.org/lkml/2008/4/28/52 with mtrr_chunk_size=1g, and you should get you should get > reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 > reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 > reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 YH YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 6:50 ` Yinghai Lu @ 2008-04-28 8:38 ` Mika Fischer 2008-04-28 9:09 ` Yinghai Lu 0 siblings, 1 reply; 87+ messages in thread From: Mika Fischer @ 2008-04-28 8:38 UTC (permalink / raw) To: Yinghai Lu Cc: Andrew Morton, Ingo Molnar, Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, balajirrao Hi Yinghai, Yinghai Lu schrieb: >> reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 >> reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 >> reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 >> reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 >> reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 >> >> which screws up the X server's attempt to map the video memory at >> 0xd0000000. > > please try the patch at > > http://lkml.org/lkml/2008/4/28/52 > > with mtrr_chunk_size=1g, and you should get > > you should get >> reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 >> reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 >> reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 >> reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 >> reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 Wow, thanks a lot for this patch! It almost works. This is what I get with mtrr_chunk_size=1g: reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 reg04: base=0x100001000 (4096MB), size= 4KB: write-back, count=1 reg05: base=0x100002000 (4096MB), size= 8KB: write-back, count=1 reg06: base=0x100004000 (4096MB), size= 16KB: write-back, count=1 reg07: base=0x100008000 (4096MB), size= 32KB: write-back, count=1 And this is what I get without mtrr_chunk_size=1g: reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1 reg02: base=0xa0000000 (2560MB), size= 256MB: write-back, count=1 reg03: base=0xb0000000 (2816MB), size= 256MB: write-back, count=1 reg04: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 reg05: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 reg06: base=0x100001000 (4096MB), size= 4KB: write-back, count=1 reg07: base=0x100002000 (4096MB), size= 8KB: write-back, count=1 I attached these outputs and the dmesgs to the bug report: http://bugzilla.kernel.org/show_bug.cgi?id=10508 dmesg with mtrr_chunk_size=1g: http://bugzilla.kernel.org/attachment.cgi?id=15945 dmesg without mtrr_chunk_size=1g: http://bugzilla.kernel.org/attachment.cgi?id=15946 There are some warnings in the output: [ 0.000000] WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 1023MB of RAM. [ 0.000000] ------------[ cut here ]------------ [ 0.000000] WARNING: at /home/mika/src/linux-2.6/arch/x86/kernel/cpu/mtrr/main.c:1049 mtrr_trim_uncached_memory+0x118/0x250() [ 0.000000] Modules linked in: [ 0.000000] Pid: 0, comm: swapper Not tainted 2.6.25 #5 [ 0.000000] [<c01273af>] warn_on_slowpath+0x5f/0x90 [ 0.000000] [<c03a8f9d>] _spin_unlock_irqrestore+0xd/0x10 [ 0.000000] [<c0127d4a>] release_console_sem+0x1ba/0x1e0 [ 0.000000] [<c01280d8>] vprintk+0x1c8/0x3a0 [ 0.000000] [<c010ebd3>] generic_get_mtrr+0x93/0x100 [ 0.000000] [<c01282cb>] printk+0x1b/0x20 [ 0.000000] [<c05069d8>] mtrr_trim_uncached_memory+0x118/0x250 [ 0.000000] [<c0504292>] setup_arch+0x312/0x590 [ 0.000000] [<c04fd774>] start_kernel+0x64/0x3a0 [ 0.000000] ======================= [ 0.000000] ---[ end trace ca143223eefdc828 ]--- Let me know if there's anything else I can do to help! Regards, Mika ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 8:38 ` Mika Fischer @ 2008-04-28 9:09 ` Yinghai Lu 2008-04-28 9:44 ` Mika Fischer 0 siblings, 1 reply; 87+ messages in thread From: Yinghai Lu @ 2008-04-28 9:09 UTC (permalink / raw) To: Mika Fischer Cc: Andrew Morton, Ingo Molnar, Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, balajirrao On Mon, Apr 28, 2008 at 1:38 AM, Mika Fischer <mika.fischer@zoopnet.de> wrote: > Hi Yinghai, > > Yinghai Lu schrieb: > > >> reg00: base=0xc0000000 (3072MB), size=1024MB: uncachable, count=1 > >> reg01: base=0x00000000 ( 0MB), size=4096MB: write-back, count=1 > >> reg02: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 > >> reg03: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > >> reg04: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > >> > >> which screws up the X server's attempt to map the video memory at > >> 0xd0000000. > > > > please try the patch at > > > > http://lkml.org/lkml/2008/4/28/52 > > > > with mtrr_chunk_size=1g, and you should get > > > > you should get > >> reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 > >> reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 > >> reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > >> reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > >> reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 > > Wow, thanks a lot for this patch! It almost works. This is what I get > with mtrr_chunk_size=1g: > > reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 > reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 > reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > reg04: base=0x100001000 (4096MB), size= 4KB: write-back, count=1 > reg05: base=0x100002000 (4096MB), size= 8KB: write-back, count=1 > reg06: base=0x100004000 (4096MB), size= 16KB: write-back, count=1 > reg07: base=0x100008000 (4096MB), size= 32KB: write-back, count=1 > > And this is what I get without mtrr_chunk_size=1g: > > reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 > reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1 > reg02: base=0xa0000000 (2560MB), size= 256MB: write-back, count=1 > reg03: base=0xb0000000 (2816MB), size= 256MB: write-back, count=1 > reg04: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > reg05: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > reg06: base=0x100001000 (4096MB), size= 4KB: write-back, count=1 > reg07: base=0x100002000 (4096MB), size= 8KB: write-back, count=1 > > I attached these outputs and the dmesgs to the bug report: > > http://bugzilla.kernel.org/show_bug.cgi?id=10508 > > dmesg with mtrr_chunk_size=1g: > http://bugzilla.kernel.org/attachment.cgi?id=15945 > > dmesg without mtrr_chunk_size=1g: > http://bugzilla.kernel.org/attachment.cgi?id=15946 > thanks for testing please check http://lkml.org/lkml/2008/4/28/115 also, can you try 64bit too? YH ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 9:09 ` Yinghai Lu @ 2008-04-28 9:44 ` Mika Fischer 2008-04-28 9:58 ` Gabriel C 0 siblings, 1 reply; 87+ messages in thread From: Mika Fischer @ 2008-04-28 9:44 UTC (permalink / raw) To: Yinghai Lu Cc: Andrew Morton, Ingo Molnar, Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, balajirrao Yinghai Lu schrieb: >>> you should get >>>> reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 >>>> reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 >>>> reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 >>>> reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 >>>> reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 > please check > http://lkml.org/lkml/2008/4/28/115 OK, this time it worked! With mtrr_chunk_size=1g: reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 Without mtrr_chunk_size=1g: reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1 reg02: base=0xa0000000 (2560MB), size= 256MB: write-back, count=1 reg03: base=0xb0000000 (2816MB), size= 256MB: write-back, count=1 reg04: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 reg05: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 reg06: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 Both seem equivalent and correct. There are also no warnings anymore in the dmesg output: With mtrr_chunk_size=1g: http://bugzilla.kernel.org/attachment.cgi?id=15950 Without mtrr_chunk_size=1g: http://bugzilla.kernel.org/attachment.cgi?id=15951 > also, can you try 64bit too? I'm not sure how to do this. Can I compile it under 32bit Linux? If not that will be difficult since I don't have space left for a 64bit installation on my hard-drive. Maybe Gabiel C can test 64bit? Regards, Mika ^ permalink raw reply [flat|nested] 87+ messages in thread
* Re: [PATCH] x86_32: trim memory by updating e820 v3 2008-04-28 9:44 ` Mika Fischer @ 2008-04-28 9:58 ` Gabriel C 0 siblings, 0 replies; 87+ messages in thread From: Gabriel C @ 2008-04-28 9:58 UTC (permalink / raw) To: Mika Fischer Cc: Yinghai Lu, Andrew Morton, Ingo Molnar, Andi Kleen, H. Peter Anvin, LKML, Jesse Barnes, balajirrao Mika Fischer wrote: > Yinghai Lu schrieb: >>>> you should get >>>>> reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 >>>>> reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 >>>>> reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 >>>>> reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 >>>>> reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 >> please check >> http://lkml.org/lkml/2008/4/28/115 > > OK, this time it worked! > > With mtrr_chunk_size=1g: > reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 > reg01: base=0x80000000 (2048MB), size=1024MB: write-back, count=1 > reg02: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > reg03: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > reg04: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 > > Without mtrr_chunk_size=1g: > reg00: base=0x00000000 ( 0MB), size=2048MB: write-back, count=1 > reg01: base=0x80000000 (2048MB), size= 512MB: write-back, count=1 > reg02: base=0xa0000000 (2560MB), size= 256MB: write-back, count=1 > reg03: base=0xb0000000 (2816MB), size= 256MB: write-back, count=1 > reg04: base=0xbf700000 (3063MB), size= 1MB: uncachable, count=1 > reg05: base=0xbf800000 (3064MB), size= 8MB: uncachable, count=1 > reg06: base=0x100000000 (4096MB), size=1024MB: write-back, count=1 > > Both seem equivalent and correct. > > There are also no warnings anymore in the dmesg output: > With mtrr_chunk_size=1g: > http://bugzilla.kernel.org/attachment.cgi?id=15950 > > Without mtrr_chunk_size=1g: > http://bugzilla.kernel.org/attachment.cgi?id=15951 > >> also, can you try 64bit too? > > I'm not sure how to do this. Can I compile it under 32bit Linux? If not that > will be difficult since I don't have space left for a 64bit installation on my > hard-drive. Maybe Gabiel C can test 64bit? Yes sure, done already :) I could test 32/64 bit on this box if needed. > > Regards, > Mika Gabriel ^ permalink raw reply [flat|nested] 87+ messages in thread
* [PATCH] x86_64: update e820 instead of updating end_pfn v3 [not found] ` <200801202255.02645.yinghai.lu@sun.com> [not found] ` <200801202255.58642.yinghai.lu@sun.com> @ 2008-01-21 6:57 ` Yinghai Lu 1 sibling, 0 replies; 87+ messages in thread From: Yinghai Lu @ 2008-01-21 6:57 UTC (permalink / raw) To: Andi Kleen, Ingo Molnar; +Cc: H. Peter Anvin, LKML, Jesse Barnes, Andrew Morton [PATCH] x86_64: update e820 instead of updating end_pfn v3 need to apply after x86_64 check if Tom2 is enabled when mtrr is not covering all e820 table, need to trim the ram, need to update e820 so we can reuse some code for x86_32. after we add early_identify_cpu for x86_32, and move mtrr_bp_init early for x86_32 Signed-off-by: Yinghai Lu <yinghai.lu@sun.com> Index: linux-2.6/arch/x86/kernel/cpu/mtrr/main.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/main.c +++ linux-2.6/arch/x86/kernel/cpu/mtrr/main.c @@ -624,6 +624,7 @@ static struct sysdev_driver mtrr_sysdev_ .resume = mtrr_restore, }; +#ifdef CONFIG_X86_64 static int disable_mtrr_trim; static int __init disable_mtrr_trim_setup(char *str) @@ -633,8 +634,6 @@ static int __init disable_mtrr_trim_setu } early_param("disable_mtrr_trim", disable_mtrr_trim_setup); -#ifdef CONFIG_X86_64 - /* * Newer AMD K8s and later CPUs have a special magic MSR way to force WB * for memory >4GB. Check for that here. @@ -644,7 +643,7 @@ early_param("disable_mtrr_trim", disable #define Tom2Enabled (1U << 21) #define Tom2ForceMemTypeWB (1U << 22) -static __init int amd_special_default_mtrr(void) +static __init int amd_special_default_mtrr(unsigned long end_pfn) { u32 l, h; @@ -678,10 +677,11 @@ static __init int amd_special_default_mt * memory off the end by adjusting end_pfn, removing it from the kernel's * allocation pools, warning the user with an obnoxious message. */ -void __init mtrr_trim_uncached_memory(void) +int __init mtrr_trim_uncached_memory(unsigned long end_pfn) { unsigned long i, base, size, highest_addr = 0, def, dummy; mtrr_type type; + u64 trim_start, trim_size; /* * Make sure we only trim uncachable memory on machines that @@ -690,7 +690,7 @@ void __init mtrr_trim_uncached_memory(vo rdmsr(MTRRdefType_MSR, def, dummy); def &= 0xff; if (!is_cpu(INTEL) || disable_mtrr_trim || def != MTRR_TYPE_UNCACHABLE) - return; + return 0; /* Find highest cached pfn */ for (i = 0; i < num_var_ranges; i++) { @@ -703,8 +703,8 @@ void __init mtrr_trim_uncached_memory(vo highest_addr = base + size; } - if (amd_special_default_mtrr()) - return; + if (amd_special_default_mtrr(end_pfn)) + return 0; if ((highest_addr >> PAGE_SHIFT) < end_pfn) { printk(KERN_WARNING "***************\n"); @@ -713,8 +713,18 @@ void __init mtrr_trim_uncached_memory(vo "memory, trimmed %ld pages\n", end_pfn - (highest_addr >> PAGE_SHIFT)); printk(KERN_WARNING "***************\n"); - end_pfn = highest_addr >> PAGE_SHIFT; + + printk(KERN_INFO "update e820 for mtrr\n"); + trim_start = highest_addr; + trim_size = end_pfn; + trim_size <<= PAGE_SHIFT; + trim_size -= trim_start; + add_memory_region(trim_start, trim_size, E820_RESERVED); + update_e820(); + return 1; } + + return 0; } #endif Index: linux-2.6/arch/x86/kernel/setup_64.c =================================================================== --- linux-2.6.orig/arch/x86/kernel/setup_64.c +++ linux-2.6/arch/x86/kernel/setup_64.c @@ -324,9 +324,12 @@ void __init setup_arch(char **cmdline_p) * we are rounding upwards: */ end_pfn = e820_end_of_ram(); - /* Trim memory not covered by WB MTRRs */ + /* update e820 for memory not covered by WB MTRRs */ mtrr_bp_init(); - mtrr_trim_uncached_memory(); + if (mtrr_trim_uncached_memory(end_pfn)) { + e820_register_active_regions(0, 0, -1UL); + end_pfn = e820_end_of_ram(); + } num_physpages = end_pfn; Index: linux-2.6/include/asm-x86/mtrr.h =================================================================== --- linux-2.6.orig/include/asm-x86/mtrr.h +++ linux-2.6/include/asm-x86/mtrr.h @@ -97,7 +97,7 @@ extern int mtrr_del_page (int reg, unsig extern void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi); extern void mtrr_ap_init(void); extern void mtrr_bp_init(void); -extern void mtrr_trim_uncached_memory(void); +extern int mtrr_trim_uncached_memory(unsigned long end_pfn); # else #define mtrr_save_fixed_ranges(arg) do {} while (0) #define mtrr_save_state() do {} while (0) @@ -121,8 +121,9 @@ static __inline__ int mtrr_del_page (int { return -ENODEV; } -static __inline__ void mtrr_trim_uncached_memory(void) +static __inline__ int mtrr_trim_uncached_memory(unsigned long end_pfn) { + return 0; } static __inline__ void mtrr_centaur_report_mcr(int mcr, u32 lo, u32 hi) {;} ^ permalink raw reply [flat|nested] 87+ messages in thread
end of thread, other threads:[~2008-04-29 22:24 UTC | newest] Thread overview: 87+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-01-20 4:45 [PATCH] x86: disable_mtrr_trim only need for x86_64 Yinghai Lu 2008-01-20 5:37 ` H. Peter Anvin 2008-01-20 6:55 ` Yinghai Lu 2008-01-20 8:17 ` [PATCH] x86_64: update e820 instead of updating end_pfn Yinghai Lu 2008-01-20 9:20 ` Ingo Molnar 2008-01-20 15:08 ` Andi Kleen 2008-01-21 5:40 ` [PATCH] x86_64: update e820 instead of updating end_pfn v2 Yinghai Lu 2008-01-21 5:44 ` [PATCH] x86_32: trim memory by updating e820 Yinghai Lu 2008-01-21 5:58 ` [PATCH] x86_64: update e820 instead of updating end_pfn v2 Andi Kleen 2008-01-21 6:05 ` Harvey Harrison 2008-01-21 6:08 ` Andi Kleen 2008-01-21 6:14 ` Li Zefan 2008-01-21 6:57 ` [PATCH] x86_64: check if Tom2 is enabled Yinghai Lu 2008-01-21 17:24 ` Cyrill Gorcunov 2008-01-21 17:39 ` H. Peter Anvin 2008-01-21 17:49 ` Cyrill Gorcunov 2008-01-21 18:03 ` Andi Kleen 2008-01-21 18:09 ` Cyrill Gorcunov 2008-01-21 18:15 ` H. Peter Anvin 2008-01-21 18:46 ` Andi Kleen 2008-01-21 0:00 ` [PATCH] x86_64: update e820 instead of updating end_pfn Yinghai Lu [not found] ` <200801202255.02645.yinghai.lu@sun.com> [not found] ` <200801202255.58642.yinghai.lu@sun.com> 2008-01-21 6:56 ` [PATCH] x86_32: trim memory by updating e820 v2 Yinghai Lu 2008-01-21 16:30 ` Jesse Barnes 2008-01-21 19:14 ` Justin Piszcz 2008-01-21 20:09 ` Yinghai Lu 2008-01-21 21:37 ` Justin Piszcz 2008-01-23 3:50 ` Yinghai Lu 2008-01-26 0:01 ` Justin Piszcz 2008-01-26 0:16 ` Yinghai Lu 2008-01-26 0:37 ` Justin Piszcz 2008-01-28 15:09 ` Ingo Molnar 2008-01-28 18:07 ` Justin Piszcz 2008-01-22 16:51 ` Ingo Molnar 2008-01-23 0:23 ` [PATCH] x86_32: trim memory by updating e820 v3 Yinghai Lu 2008-04-26 10:56 ` Andrew Morton 2008-04-26 12:56 ` Gabriel C 2008-04-27 1:05 ` Yinghai Lu 2008-04-28 18:07 ` Eric W. Biederman 2008-04-28 23:16 ` Yinghai Lu 2008-04-29 10:31 ` Ingo Molnar 2008-04-29 17:29 ` Eric W. Biederman 2008-04-29 18:40 ` Yinghai Lu 2008-04-29 19:19 ` Eric W. Biederman 2008-04-29 19:44 ` Yinghai Lu 2008-04-29 20:02 ` Eric W. Biederman 2008-04-28 6:44 ` Yinghai Lu 2008-04-28 9:18 ` Gabriel C 2008-04-28 9:34 ` Yinghai Lu 2008-04-28 9:54 ` Gabriel C 2008-04-28 10:03 ` Gabriel C 2008-04-28 10:07 ` Mika Fischer 2008-04-28 19:03 ` Yinghai Lu 2008-04-28 13:53 ` Ingo Molnar 2008-04-28 14:11 ` Mika Fischer 2008-04-28 14:24 ` Gabriel C 2008-04-28 19:06 ` Yinghai Lu 2008-04-28 19:38 ` Gabriel C 2008-04-28 20:45 ` Gabriel C 2008-04-28 21:19 ` Gabriel C 2008-04-28 22:03 ` Yinghai Lu 2008-04-28 22:56 ` Gabriel C 2008-04-28 23:23 ` Yinghai Lu 2008-04-29 1:05 ` Gabriel C 2008-04-29 2:41 ` Yinghai Lu 2008-04-29 10:34 ` Ingo Molnar 2008-04-29 10:42 ` Yinghai Lu 2008-04-28 19:08 ` Yinghai Lu 2008-04-28 19:46 ` Gabriel C 2008-04-28 14:15 ` Gabriel C 2008-04-28 16:09 ` Jesse Barnes 2008-04-28 16:31 ` Mika Fischer 2008-04-28 16:55 ` Jesse Barnes 2008-04-29 10:37 ` Ingo Molnar 2008-04-29 12:40 ` Andrew Morton 2008-04-29 15:52 ` Jesse Barnes 2008-04-29 22:03 ` [patch] PCI: export resource_wc in pci sysfs Ingo Molnar 2008-04-29 22:24 ` Andrew Morton 2008-04-27 0:57 ` [PATCH] x86_32: trim memory by updating e820 v3 Yinghai Lu 2008-04-27 8:21 ` Mika Fischer 2008-04-27 1:22 ` Yinghai Lu 2008-04-27 8:29 ` Mika Fischer 2008-04-28 6:50 ` Yinghai Lu 2008-04-28 8:38 ` Mika Fischer 2008-04-28 9:09 ` Yinghai Lu 2008-04-28 9:44 ` Mika Fischer 2008-04-28 9:58 ` Gabriel C 2008-01-21 6:57 ` [PATCH] x86_64: update e820 instead of updating end_pfn v3 Yinghai Lu
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).