* [BUG 2.6.29_rc8] BIOS Bug: CPU MTRRs don't cover all of memory, losing 0MB of RAM.
@ 2009-03-16 13:48 Ozan Çağlayan
2009-03-16 18:21 ` Yinghai Lu
0 siblings, 1 reply; 8+ messages in thread
From: Ozan Çağlayan @ 2009-03-16 13:48 UTC (permalink / raw)
To: linux-kernel
Hi,
Just compiled and tried to boot it on an HP ProLiant DL580 G5. Here's the
interesting part:
..
-- last_pfn = 0x82ffff max_arch_pfn = 0x1000000
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 0MB of RAM.
------------[ cut here ]------------
WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1655 mtrr_trim_uncached_memory+0x2a9/0x2cd()
Hardware name: ProLiant DL580 G5
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.29_rc8-115 #1
Call Trace:
[<c013134d>] warn_slowpath+0x71/0xa8
[<c039971c>] ? _spin_unlock_irqrestore+0x19/0x1f
[<c039971c>] ? _spin_unlock_irqrestore+0x19/0x1f
[<c01319c4>] ? release_console_sem+0x185/0x1b2
[<c0131e49>] ? vprintk+0x280/0x2a5
[<c03973da>] ? printk+0xf/0x15
[<c053423f>] mtrr_trim_uncached_memory+0x2a9/0x2cd
[<c052f4bd>] setup_arch+0x439/0x99e
[<c01319c4>] ? release_console_sem+0x185/0x1b2
[<c0131e49>] ? vprintk+0x280/0x2a5
[<c0531b37>] ? __reserve_early+0xe4/0xf8
[<c03973da>] ? printk+0xf/0x15
[<c052b5b6>] start_kernel+0x7b/0x345
[<c052b085>] __init_begin+0x85/0x8d
---[ end trace 4eaa2a86a8e2da22 ]---
update e820 for mtrr
..
This is a quite generic x86 desktop kernel with only the
following differences for the server:
CONFIG_X86_GENERICARCH=y
CONFIG_X86_BIGSMP=y
CONFIG_MCORE2=y
CONFIG_HIGHMEM64G=y
# CONFIG_X86_GENERIC is not set
I didn't want to add full dmesg and config for not flooding the e-mail but
if you need them or other output/information, i can send them.
Thanks,
Ozan Çağlayan
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [BUG 2.6.29_rc8] BIOS Bug: CPU MTRRs don't cover all of memory, losing 0MB of RAM.
2009-03-16 13:48 [BUG 2.6.29_rc8] BIOS Bug: CPU MTRRs don't cover all of memory, losing 0MB of RAM Ozan Çağlayan
@ 2009-03-16 18:21 ` Yinghai Lu
2009-03-16 20:17 ` Ozan Çağlayan
0 siblings, 1 reply; 8+ messages in thread
From: Yinghai Lu @ 2009-03-16 18:21 UTC (permalink / raw)
To: Ozan Çağlayan; +Cc: linux-kernel
On Mon, Mar 16, 2009 at 6:48 AM, Ozan Çağlayan <ozan@pardus.org.tr> wrote:
> Hi,
>
> Just compiled and tried to boot it on an HP ProLiant DL580 G5. Here's the
> interesting part:
>
> ..
> -- last_pfn = 0x82ffff max_arch_pfn = 0x1000000
> x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 0MB of RAM.
> ------------[ cut here ]------------
> WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1655 mtrr_trim_uncached_memory+0x2a9/0x2cd()
> Hardware name: ProLiant DL580 G5
> Modules linked in:
> Pid: 0, comm: swapper Not tainted 2.6.29_rc8-115 #1
> Call Trace:
> [<c013134d>] warn_slowpath+0x71/0xa8
> [<c039971c>] ? _spin_unlock_irqrestore+0x19/0x1f
> [<c039971c>] ? _spin_unlock_irqrestore+0x19/0x1f
> [<c01319c4>] ? release_console_sem+0x185/0x1b2
> [<c0131e49>] ? vprintk+0x280/0x2a5
> [<c03973da>] ? printk+0xf/0x15
> [<c053423f>] mtrr_trim_uncached_memory+0x2a9/0x2cd
> [<c052f4bd>] setup_arch+0x439/0x99e
> [<c01319c4>] ? release_console_sem+0x185/0x1b2
> [<c0131e49>] ? vprintk+0x280/0x2a5
> [<c0531b37>] ? __reserve_early+0xe4/0xf8
> [<c03973da>] ? printk+0xf/0x15
> [<c052b5b6>] start_kernel+0x7b/0x345
> [<c052b085>] __init_begin+0x85/0x8d
> ---[ end trace 4eaa2a86a8e2da22 ]---
> update e820 for mtrr
> ..
>
> This is a quite generic x86 desktop kernel with only the
> following differences for the server:
>
> CONFIG_X86_GENERICARCH=y
> CONFIG_X86_BIGSMP=y
> CONFIG_MCORE2=y
> CONFIG_HIGHMEM64G=y
> # CONFIG_X86_GENERIC is not set
>
> I didn't want to add full dmesg and config for not flooding the e-mail but
> if you need them or other output/information, i can send them.
>
can you check tip/master?
http://people.redhat.com/mingo/tip.git/readme.txt
and post boot log.
YH
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [BUG 2.6.29_rc8] BIOS Bug: CPU MTRRs don't cover all of memory, losing 0MB of RAM.
2009-03-16 18:21 ` Yinghai Lu
@ 2009-03-16 20:17 ` Ozan Çağlayan
2009-03-16 22:00 ` Yinghai Lu
0 siblings, 1 reply; 8+ messages in thread
From: Ozan Çağlayan @ 2009-03-16 20:17 UTC (permalink / raw)
To: Yinghai Lu; +Cc: linux-kernel
Yinghai Lu wrote:
> can you check tip/master?
>
> http://people.redhat.com/mingo/tip.git/readme.txt
>
> and post boot log.
I compiled tip/master with the same configuration. Here's the head of the dmesg:
(BTW, I'm not getting this backtrace with 2.6.25.20. I know its rather old but maybe
it will help)
---
Initializing cgroup subsys cpuset
Linux version 2.6.29-rc8-tip-tip (root@stinson) (gcc version 4.3.2 (Pardus Linux) ) #1 SMP Mon Mar 16 21:26:14 EET 2009
KERNEL supported cpus:
Intel GenuineIntel
AMD AuthenticAMD
NSC Geode by NSC
Cyrix CyrixInstead
Centaur CentaurHauls
Transmeta GenuineTMx86
Transmeta TransmetaCPU
UMC UMC UMC UMC
BIOS-provided physical RAM map:
BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
BIOS-e820: 0000000000100000 - 00000000cfd43000 (usable)
BIOS-e820: 00000000cfd43000 - 00000000cfd4c000 (ACPI data)
BIOS-e820: 00000000cfd4c000 - 00000000cfd4d000 (usable)
BIOS-e820: 00000000cfd4d000 - 00000000d0000000 (reserved)
BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
BIOS-e820: 00000000fec00000 - 00000000fed00000 (reserved)
BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
BIOS-e820: 0000000100000000 - 000000082ffff000 (usable)
DMI 2.5 present.
last_pfn = 0x82ffff max_arch_pfn = 0x1000000
MTRR default type: uncachable
MTRR fixed ranges enabled:
00000-9FFFF write-back
A0000-BFFFF uncachable
C0000-FFFFF write-protect
MTRR variable ranges enabled:
0 base 0000000000 mask 0000000000 write-back
1 base 00CFF00000 mask FFFFF00000 uncachable
2 base 00D0000000 mask FFF0000000 uncachable
3 base 00E0000000 mask FFE0000000 uncachable
4 base 0000004000 mask FFFFFFF000 uncachable
5 base 0000005000 mask FFFFFFF000 uncachable
6 base 0000006000 mask FFFFFFF000 uncachable
7 base 0000007000 mask FFFFFFF000 uncachable
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
e820 update range: 0000000000004000 - 0000000000008000 (usable) ==> (reserved)
e820 update range: 00000000cff00000 - 0000000100000000 (usable) ==> (reserved)
WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 0MB of RAM.
------------[ cut here ]------------
WARNING: at arch/x86/kernel/cpu/mtrr/cleanup.c:1079 mtrr_trim_uncached_memory+0x2a9/0x2cd()
Hardware name: ProLiant DL580 G5
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.29-rc8-tip-tip #1
Call Trace:
[<c0133871>] warn_slowpath+0x71/0xa8
[<c011e23a>] ? default_spin_lock_flags+0x9/0xb
[<c03aad3c>] ? _spin_unlock_irqrestore+0x17/0x1b
[<c011e23a>] ? default_spin_lock_flags+0x9/0xb
[<c03aad3c>] ? _spin_unlock_irqrestore+0x17/0x1b
[<c0133edd>] ? release_console_sem+0x176/0x1a3
[<c0134358>] ? vprintk+0x276/0x299
[<c03a87cc>] ? printk+0xf/0x13
[<c054aece>] mtrr_trim_uncached_memory+0x2a9/0x2cd
[<c0545cf5>] setup_arch+0x43c/0x9ab
[<c0133edd>] ? release_console_sem+0x176/0x1a3
[<c0134358>] ? vprintk+0x276/0x299
[<c0134358>] ? vprintk+0x276/0x299
[<c0548759>] ? __reserve_early+0xe4/0xf8
[<c03a87cc>] ? printk+0xf/0x13
[<c0543580>] start_kernel+0x77/0x323
[<c0543085>] __init_begin+0x85/0x8d
---[ end trace 4eaa2a86a8e2da22 ]---
update e820 for mtrr
--
Ozan Çağlayan
<ozan_at_pardus.org.tr>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [BUG 2.6.29_rc8] BIOS Bug: CPU MTRRs don't cover all of memory, losing 0MB of RAM.
2009-03-16 20:17 ` Ozan Çağlayan
@ 2009-03-16 22:00 ` Yinghai Lu
2009-03-16 22:42 ` Ozan Çağlayan
0 siblings, 1 reply; 8+ messages in thread
From: Yinghai Lu @ 2009-03-16 22:00 UTC (permalink / raw)
To: Ozan Çağlayan, Ingo Molnar, Thomas Gleixner,
H. Peter Anvin, Andrew Morton
Cc: linux-kernel
Ozan Çağlayan wrote:
> Yinghai Lu wrote:
>
>> can you check tip/master?
>>
>> http://people.redhat.com/mingo/tip.git/readme.txt
>>
>> and post boot log.
>
> I compiled tip/master with the same configuration. Here's the head of the dmesg:
> (BTW, I'm not getting this backtrace with 2.6.25.20. I know its rather old but maybe
> it will help)
>
> ---
>
> Initializing cgroup subsys cpuset
> Linux version 2.6.29-rc8-tip-tip (root@stinson) (gcc version 4.3.2 (Pardus Linux) ) #1 SMP Mon Mar 16 21:26:14 EET 2009
> KERNEL supported cpus:
> Intel GenuineIntel
> AMD AuthenticAMD
> NSC Geode by NSC
> Cyrix CyrixInstead
> Centaur CentaurHauls
> Transmeta GenuineTMx86
> Transmeta TransmetaCPU
> UMC UMC UMC UMC
> BIOS-provided physical RAM map:
> BIOS-e820: 0000000000000000 - 000000000009f400 (usable)
> BIOS-e820: 000000000009f400 - 00000000000a0000 (reserved)
> BIOS-e820: 00000000000f0000 - 0000000000100000 (reserved)
> BIOS-e820: 0000000000100000 - 00000000cfd43000 (usable)
> BIOS-e820: 00000000cfd43000 - 00000000cfd4c000 (ACPI data)
> BIOS-e820: 00000000cfd4c000 - 00000000cfd4d000 (usable)
> BIOS-e820: 00000000cfd4d000 - 00000000d0000000 (reserved)
> BIOS-e820: 00000000e0000000 - 00000000f0000000 (reserved)
> BIOS-e820: 00000000fec00000 - 00000000fed00000 (reserved)
> BIOS-e820: 00000000fee00000 - 00000000fee10000 (reserved)
> BIOS-e820: 00000000ffc00000 - 0000000100000000 (reserved)
> BIOS-e820: 0000000100000000 - 000000082ffff000 (usable)
> DMI 2.5 present.
> last_pfn = 0x82ffff max_arch_pfn = 0x1000000
> MTRR default type: uncachable
> MTRR fixed ranges enabled:
> 00000-9FFFF write-back
> A0000-BFFFF uncachable
> C0000-FFFFF write-protect
> MTRR variable ranges enabled:
> 0 base 0000000000 mask 0000000000 write-back
> 1 base 00CFF00000 mask FFFFF00000 uncachable
> 2 base 00D0000000 mask FFF0000000 uncachable
> 3 base 00E0000000 mask FFE0000000 uncachable
> 4 base 0000004000 mask FFFFFFF000 uncachable
> 5 base 0000005000 mask FFFFFFF000 uncachable
> 6 base 0000006000 mask FFFFFFF000 uncachable
> 7 base 0000007000 mask FFFFFFF000 uncachable
> x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
> get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
> get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
> get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
> get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
> get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
> get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
> get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
> e820 update range: 0000000000004000 - 0000000000008000 (usable) ==> (reserved)
> e820 update range: 00000000cff00000 - 0000000100000000 (usable) ==> (reserved)
> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 0MB of RAM.
> ------------[ cut here ]------------
> WARNING: at arch/x86/kernel/cpu/mtrr/cleanup.c:1079 mtrr_trim_uncached_memory+0x2a9/0x2cd()
> Hardware name: ProLiant DL580 G5
> Modules linked in:
> Pid: 0, comm: swapper Not tainted 2.6.29-rc8-tip-tip #1
> Call Trace:
> [<c0133871>] warn_slowpath+0x71/0xa8
> [<c011e23a>] ? default_spin_lock_flags+0x9/0xb
> [<c03aad3c>] ? _spin_unlock_irqrestore+0x17/0x1b
> [<c011e23a>] ? default_spin_lock_flags+0x9/0xb
> [<c03aad3c>] ? _spin_unlock_irqrestore+0x17/0x1b
> [<c0133edd>] ? release_console_sem+0x176/0x1a3
> [<c0134358>] ? vprintk+0x276/0x299
> [<c03a87cc>] ? printk+0xf/0x13
> [<c054aece>] mtrr_trim_uncached_memory+0x2a9/0x2cd
> [<c0545cf5>] setup_arch+0x43c/0x9ab
> [<c0133edd>] ? release_console_sem+0x176/0x1a3
> [<c0134358>] ? vprintk+0x276/0x299
> [<c0134358>] ? vprintk+0x276/0x299
> [<c0548759>] ? __reserve_early+0xe4/0xf8
> [<c03a87cc>] ? printk+0xf/0x13
> [<c0543580>] start_kernel+0x77/0x323
> [<c0543085>] __init_begin+0x85/0x8d
> ---[ end trace 4eaa2a86a8e2da22 ]---
> update e820 for mtrr
>
please check
[PATCH] x86: workaround system with strange var MTRR
Impact: don't trim e820 according to wrong mtrr
Ozan report his branded server emit strange warning.
it turns out MTRR is some wrong.
Ignore those strange range, and don't trim e820. just emit one warning about
BIOS
Reported-by: Ozan Çağlayan <ozan_at_pardus.org.tr>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
arch/x86/kernel/cpu/mtrr/cleanup.c | 13 ++++++++++++-
arch/x86/kernel/cpu/mtrr/main.c | 16 ++++++++--------
arch/x86/kernel/cpu/mtrr/mtrr.h | 1 +
3 files changed, 21 insertions(+), 9 deletions(-)
Index: linux-2.6/arch/x86/kernel/cpu/mtrr/cleanup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ linux-2.6/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -186,9 +186,20 @@ x86_get_mtrr_mem_range(struct res_range
type != MTRR_TYPE_WRPROT)
continue;
size = range_state[i].size_pfn;
+ base = range_state[i].base_pfn;
+ if (base < (1<<(20-PAGE_SHIFT)) && mtrr_state.have_fixed &&
+ (mtrr_state.enabled & 1)) {
+ /* var MTRR contain UC below 1M ? skip it*/
+ printk(KERN_WARNING "WARNING: BIOS bug: VAR MTRR "
+ "contains strange UC entry under 1M, check "
+ "with your system vendor!\n");
+ if (base + size < (1<<(20-PAGE_SHIFT)))
+ continue;
+ size -= (1<<(20-PAGE_SHIFT)) - base;
+ base = 1<<(20-PAGE_SHIFT);
+ }
if (!size)
continue;
- base = range_state[i].base_pfn;
subtract_range(range, base, base + size - 1);
}
if (extra_remove_size)
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
@@ -79,6 +79,7 @@ extern struct mtrr_ops * mtrr_if;
extern unsigned int num_var_ranges;
extern u64 mtrr_tom2;
+extern struct mtrr_state_type mtrr_state;
void mtrr_state_warn(void);
const char *mtrr_attrib_to_str(int x);
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
@@ -574,7 +574,7 @@ struct mtrr_value {
unsigned long lsize;
};
-static struct mtrr_value mtrr_state[MTRR_MAX_VAR_RANGES];
+static struct mtrr_value mtrr_value[MTRR_MAX_VAR_RANGES];
static int mtrr_save(struct sys_device * sysdev, pm_message_t state)
{
@@ -582,9 +582,9 @@ static int mtrr_save(struct sys_device *
for (i = 0; i < num_var_ranges; i++) {
mtrr_if->get(i,
- &mtrr_state[i].lbase,
- &mtrr_state[i].lsize,
- &mtrr_state[i].ltype);
+ &mtrr_value[i].lbase,
+ &mtrr_value[i].lsize,
+ &mtrr_value[i].ltype);
}
return 0;
}
@@ -594,11 +594,11 @@ static int mtrr_restore(struct sys_devic
int i;
for (i = 0; i < num_var_ranges; i++) {
- if (mtrr_state[i].lsize)
+ if (mtrr_value[i].lsize)
set_mtrr(i,
- mtrr_state[i].lbase,
- mtrr_state[i].lsize,
- mtrr_state[i].ltype);
+ mtrr_value[i].lbase,
+ mtrr_value[i].lsize,
+ mtrr_value[i].ltype);
}
return 0;
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [BUG 2.6.29_rc8] BIOS Bug: CPU MTRRs don't cover all of memory, losing 0MB of RAM.
2009-03-16 22:00 ` Yinghai Lu
@ 2009-03-16 22:42 ` Ozan Çağlayan
2009-03-16 22:52 ` Yinghai Lu
2009-03-16 23:33 ` [PATCH] x86: workaround system with stange var MTRR -v2 Yinghai Lu
0 siblings, 2 replies; 8+ messages in thread
From: Ozan Çağlayan @ 2009-03-16 22:42 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Andrew Morton,
linux-kernel
Yinghai Lu wrote:
> please check
>
> [PATCH] x86: workaround system with strange var MTRR
>
Thanks for your interest.
Oops is now replaced with a warning after applying the patch on top of tip/master.
BTW, do that kind of BIOS bugs have a negative impact on the performance of the system?
I'm sending the head of dmesg. And also I just noticed that there were MTRR related
stuff at the tail of the log buffer(with/without the patch). I'm posting them also:
--
MTRR default type: uncachable
MTRR fixed ranges enabled:
00000-9FFFF write-back
A0000-BFFFF uncachable
C0000-FFFFF write-protect
MTRR variable ranges enabled:
0 base 0000000000 mask 0000000000 write-back
1 base 00CFF00000 mask FFFFF00000 uncachable
2 base 00D0000000 mask FFF0000000 uncachable
3 base 00E0000000 mask FFE0000000 uncachable
4 base 0000004000 mask FFFFFFF000 uncachable
5 base 0000005000 mask FFFFFFF000 uncachable
6 base 0000006000 mask FFFFFFF000 uncachable
7 base 0000007000 mask FFFFFFF000 uncachable
x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
WARNING: BIOS bug: VAR MTRR contains strange UC entry under 1M, check with your system vendor!
WARNING: BIOS bug: VAR MTRR contains strange UC entry under 1M, check with your system vendor!
WARNING: BIOS bug: VAR MTRR contains strange UC entry under 1M, check with your system vendor!
WARNING: BIOS bug: VAR MTRR contains strange UC entry under 1M, check with your system vendor!
e820 update range: 00000000cff00000 - 0000000100000000 (usable) ==> (reserved)
init_memory_mapping: 0000000000000000-00000000379fe000
0000000000 - 0000200000 page 4k
0000200000 - 0037800000 page 2M
0037800000 - 00379fe000 page 4k
...
...
...
...
NET: Registered protocol family 10
lo: Disabled Privacy Extensions
ADDRCONF(NETDEV_UP): eth1: link is not ready
get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
mtrr: type mismatch for d8000000,4000000 old: write-back new: write-combining
get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
--
Ozan Çağlayan
<ozan_at_pardus.org.tr>
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [BUG 2.6.29_rc8] BIOS Bug: CPU MTRRs don't cover all of memory, losing 0MB of RAM.
2009-03-16 22:42 ` Ozan Çağlayan
@ 2009-03-16 22:52 ` Yinghai Lu
2009-03-17 9:43 ` Ingo Molnar
2009-03-16 23:33 ` [PATCH] x86: workaround system with stange var MTRR -v2 Yinghai Lu
1 sibling, 1 reply; 8+ messages in thread
From: Yinghai Lu @ 2009-03-16 22:52 UTC (permalink / raw)
To: Ozan Çağlayan
Cc: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Andrew Morton,
linux-kernel
Ozan Çağlayan wrote:
> Yinghai Lu wrote:
>
>> please check
>>
>> [PATCH] x86: workaround system with strange var MTRR
>>
>
> Thanks for your interest.
>
> Oops is now replaced with a warning after applying the patch on top of tip/master.
that is intended...
>
> BTW, do that kind of BIOS bugs have a negative impact on the performance of the system?
should not, FIXED MTRR should override VAR MTRR if fixed mtrr is enabled.
>
>
> I'm sending the head of dmesg. And also I just noticed that there were MTRR related
> stuff at the tail of the log buffer(with/without the patch). I'm posting them also:
>
> --
>
> MTRR default type: uncachable
> MTRR fixed ranges enabled:
> 00000-9FFFF write-back
> A0000-BFFFF uncachable
> C0000-FFFFF write-protect
> MTRR variable ranges enabled:
> 0 base 0000000000 mask 0000000000 write-back
> 1 base 00CFF00000 mask FFFFF00000 uncachable
> 2 base 00D0000000 mask FFF0000000 uncachable
> 3 base 00E0000000 mask FFE0000000 uncachable
> 4 base 0000004000 mask FFFFFFF000 uncachable
> 5 base 0000005000 mask FFFFFFF000 uncachable
> 6 base 0000006000 mask FFFFFFF000 uncachable
> 7 base 0000007000 mask FFFFFFF000 uncachable
> x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
> get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
> get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
> get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
> get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
> get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
> get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
> get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
> WARNING: BIOS bug: VAR MTRR contains strange UC entry under 1M, check with your system vendor!
> WARNING: BIOS bug: VAR MTRR contains strange UC entry under 1M, check with your system vendor!
> WARNING: BIOS bug: VAR MTRR contains strange UC entry under 1M, check with your system vendor!
> WARNING: BIOS bug: VAR MTRR contains strange UC entry under 1M, check with your system vendor!
you got four wrong entries
> e820 update range: 00000000cff00000 - 0000000100000000 (usable) ==> (reserved)
> init_memory_mapping: 0000000000000000-00000000379fe000
> 0000000000 - 0000200000 page 4k
> 0000200000 - 0037800000 page 2M
> 0037800000 - 00379fe000 page 4k
> ...
> ...
> ...
> ...
> NET: Registered protocol family 10
> lo: Disabled Privacy Extensions
> ADDRCONF(NETDEV_UP): eth1: link is not ready
> get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
> get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
> get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
> get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
> get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
> get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
> get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
> get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
> get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
> get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
> get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
> get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
> get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
> get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
> get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
> get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
> bnx2: eth1 NIC Copper Link is Up, 1000 Mbps full duplex, receive & transmit flow control ON
> ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready
> get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
> get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
> get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
> get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
> get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
> get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
> get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
> get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
> get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
> get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
> get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
> get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
> get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
> get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
> get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
> get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
> get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
> get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
> get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
> get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
> get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
> get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
> get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
> get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
> get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
> mtrr: type mismatch for d8000000,4000000 old: write-back new: write-combining
> get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
> get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
> get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
> get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
> get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
> get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
> get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
> get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
>
you may try MTRR cleanup
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
it should clear the strange entries and find some spare one for your driver that need ...
it will get some performance improvement.
or talk to your system vendor to get a new BIOS.
YH
^ permalink raw reply [flat|nested] 8+ messages in thread
* [PATCH] x86: workaround system with stange var MTRR -v2
2009-03-16 22:42 ` Ozan Çağlayan
2009-03-16 22:52 ` Yinghai Lu
@ 2009-03-16 23:33 ` Yinghai Lu
1 sibling, 0 replies; 8+ messages in thread
From: Yinghai Lu @ 2009-03-16 23:33 UTC (permalink / raw)
To: Ingo Molnar, Thomas Gleixner, H. Peter Anvin, Andrew Morton
Cc: linux-kernel, Ozan Çağlayan
Impact: don't trim e820 according to wrong mtrr
Ozan report his branded server emit strange warning.
it turns out MTRR is some wrong.
Ignore those strange range, and don't trim e820. just emit one warning about
BIOS
Reported-by: Ozan Çağlayan <ozan@pardus.org.tr>
Signed-off-by: Yinghai Lu <yinghai@kernel.org>
---
arch/x86/kernel/cpu/mtrr/cleanup.c | 11 +++++++++++
arch/x86/kernel/cpu/mtrr/main.c | 16 ++++++++--------
arch/x86/kernel/cpu/mtrr/mtrr.h | 1 +
3 files changed, 20 insertions(+), 8 deletions(-)
Index: linux-2.6/arch/x86/kernel/cpu/mtrr/cleanup.c
===================================================================
--- linux-2.6.orig/arch/x86/kernel/cpu/mtrr/cleanup.c
+++ linux-2.6/arch/x86/kernel/cpu/mtrr/cleanup.c
@@ -189,6 +189,17 @@ x86_get_mtrr_mem_range(struct res_range
if (!size)
continue;
base = range_state[i].base_pfn;
+ if (base < (1<<(20-PAGE_SHIFT)) && mtrr_state.have_fixed &&
+ (mtrr_state.enabled & 1)) {
+ /* var MTRR contain UC below 1M ? skip it*/
+ printk(KERN_WARNING "WARNING: BIOS bug: VAR MTRR "
+ "contains strange UC entry under 1M, check "
+ "with your system vendor!\n");
+ if (base + size <= (1<<(20-PAGE_SHIFT)))
+ continue;
+ size -= (1<<(20-PAGE_SHIFT)) - base;
+ base = 1<<(20-PAGE_SHIFT);
+ }
subtract_range(range, base, base + size - 1);
}
if (extra_remove_size)
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
@@ -79,6 +79,7 @@ extern struct mtrr_ops * mtrr_if;
extern unsigned int num_var_ranges;
extern u64 mtrr_tom2;
+extern struct mtrr_state_type mtrr_state;
void mtrr_state_warn(void);
const char *mtrr_attrib_to_str(int x);
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
@@ -574,7 +574,7 @@ struct mtrr_value {
unsigned long lsize;
};
-static struct mtrr_value mtrr_state[MTRR_MAX_VAR_RANGES];
+static struct mtrr_value mtrr_value[MTRR_MAX_VAR_RANGES];
static int mtrr_save(struct sys_device * sysdev, pm_message_t state)
{
@@ -582,9 +582,9 @@ static int mtrr_save(struct sys_device *
for (i = 0; i < num_var_ranges; i++) {
mtrr_if->get(i,
- &mtrr_state[i].lbase,
- &mtrr_state[i].lsize,
- &mtrr_state[i].ltype);
+ &mtrr_value[i].lbase,
+ &mtrr_value[i].lsize,
+ &mtrr_value[i].ltype);
}
return 0;
}
@@ -594,11 +594,11 @@ static int mtrr_restore(struct sys_devic
int i;
for (i = 0; i < num_var_ranges; i++) {
- if (mtrr_state[i].lsize)
+ if (mtrr_value[i].lsize)
set_mtrr(i,
- mtrr_state[i].lbase,
- mtrr_state[i].lsize,
- mtrr_state[i].ltype);
+ mtrr_value[i].lbase,
+ mtrr_value[i].lsize,
+ mtrr_value[i].ltype);
}
return 0;
}
^ permalink raw reply [flat|nested] 8+ messages in thread
* Re: [BUG 2.6.29_rc8] BIOS Bug: CPU MTRRs don't cover all of memory, losing 0MB of RAM.
2009-03-16 22:52 ` Yinghai Lu
@ 2009-03-17 9:43 ` Ingo Molnar
0 siblings, 0 replies; 8+ messages in thread
From: Ingo Molnar @ 2009-03-17 9:43 UTC (permalink / raw)
To: Yinghai Lu
Cc: Ozan Çağlayan, Thomas Gleixner, H. Peter Anvin,
Andrew Morton, linux-kernel
* Yinghai Lu <yinghai@kernel.org> wrote:
> > x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> > get_mtrr: cpu0 reg00 base=0000000000 size=0010000000 write-back
> > get_mtrr: cpu0 reg01 base=00000cff00 size=0000000100 uncachable
> > get_mtrr: cpu0 reg02 base=00000d0000 size=0000010000 uncachable
> > get_mtrr: cpu0 reg03 base=00000e0000 size=0000020000 uncachable
> > get_mtrr: cpu0 reg04 base=0000000004 size=0000000001 uncachable
> > get_mtrr: cpu0 reg05 base=0000000005 size=0000000001 uncachable
> > get_mtrr: cpu0 reg06 base=0000000006 size=0000000001 uncachable
> > get_mtrr: cpu0 reg07 base=0000000007 size=0000000001 uncachable
> > WARNING: BIOS bug: VAR MTRR contains strange UC entry under 1M, check with your system vendor!
> > WARNING: BIOS bug: VAR MTRR contains strange UC entry under 1M, check with your system vendor!
> > WARNING: BIOS bug: VAR MTRR contains strange UC entry under 1M, check with your system vendor!
> > WARNING: BIOS bug: VAR MTRR contains strange UC entry under 1M, check with your system vendor!
>
> you got four wrong entries
but it's unintuitive. That warning should specify which entry is
wrong, so that we dont get these pointless duplicated lines.
Ingo
^ permalink raw reply [flat|nested] 8+ messages in thread
end of thread, other threads:[~2009-03-17 9:45 UTC | newest]
Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2009-03-16 13:48 [BUG 2.6.29_rc8] BIOS Bug: CPU MTRRs don't cover all of memory, losing 0MB of RAM Ozan Çağlayan
2009-03-16 18:21 ` Yinghai Lu
2009-03-16 20:17 ` Ozan Çağlayan
2009-03-16 22:00 ` Yinghai Lu
2009-03-16 22:42 ` Ozan Çağlayan
2009-03-16 22:52 ` Yinghai Lu
2009-03-17 9:43 ` Ingo Molnar
2009-03-16 23:33 ` [PATCH] x86: workaround system with stange var MTRR -v2 Yinghai Lu
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.