Marius Schäfer wrote:
Can you read anything out of these lines and help me?
..
WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 63MB of RAM. ------------[ cut here ]------------ WARNING: at arch/x86/kernel/cpu/mtrr/cleanup.c:971 mtrr_trim_uncached_memory+0x411/0x42e() Pid: 0, comm: swapper Not tainted 3.2.44 #7 Call Trace: [<c1017964>] ? warn_slowpath_common+0x63/0x74 [<c12f98f2>] ? mtrr_trim_uncached_memory+0x411/0x42e [<c10179f8>] ? warn_slowpath_null+0xd/0x11 [<c12f98f2>] ? mtrr_trim_uncached_memory+0x411/0x42e [<c12f5165>] ? setup_arch+0x4eb/0x9dd [<c12f3421>] ? start_kernel+0x5e/0x275 ---[ end trace 4eaa2a86a8e2da22 ]---
As Ron says, work on fixing this MTRR problem.
update e820 for mtrr modified physical RAM map: modified: 0000000000000000 - 0000000000001000 type 16 modified: 0000000000001000 - 00000000000a0000 (reserved) modified: 0000000000100000 - 0000000004000000 (reserved) modified: 0000000004000000 - 000000001dfe0000 (usable) modified: 000000001dfe0000 - 000000001e000000 type 16 last_pfn = 0x1dfe0 max_arch_pfn = 0x100000 Kernel panic - not syncing: Cannot allocate trampoline
Pid: 0, comm: swapper Tainted: G W 3.2.44 #7 Call Trace: [<c12245eb>] ? panic+0x57/0x12a [<c12f77e7>] ? setup_trampolines+0x40/0xb1 [<c12f51df>] ? setup_arch+0x565/0x9dd [<c12f3421>] ? start_kernel+0x5e/0x275
Check the kernel source to find out what the constraints are for that trampoline allocation. Maybe it must be in some region where there isn't any available RAM, which would be a bug in the memory map for this (and more?) mainboards.
Try to find out more details.
//Peter
On Thu, May 30, 2013 at 5:30 AM, Peter Stuge peter@stuge.se wrote:
Marius Schäfer wrote:
Can you read anything out of these lines and help me?
..
WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 63MB of RAM. ------------[ cut here ]------------ WARNING: at arch/x86/kernel/cpu/mtrr/cleanup.c:971 mtrr_trim_uncached_memory+0x411/0x42e() Pid: 0, comm: swapper Not tainted 3.2.44 #7 Call Trace: [<c1017964>] ? warn_slowpath_common+0x63/0x74 [<c12f98f2>] ? mtrr_trim_uncached_memory+0x411/0x42e [<c10179f8>] ? warn_slowpath_null+0xd/0x11 [<c12f98f2>] ? mtrr_trim_uncached_memory+0x411/0x42e [<c12f5165>] ? setup_arch+0x4eb/0x9dd [<c12f3421>] ? start_kernel+0x5e/0x275 ---[ end trace 4eaa2a86a8e2da22 ]---
As Ron says, work on fixing this MTRR problem.
update e820 for mtrr modified physical RAM map: modified: 0000000000000000 - 0000000000001000 type 16 modified: 0000000000001000 - 00000000000a0000 (reserved) modified: 0000000000100000 - 0000000004000000 (reserved) modified: 0000000004000000 - 000000001dfe0000 (usable) modified: 000000001dfe0000 - 000000001e000000 type 16 last_pfn = 0x1dfe0 max_arch_pfn = 0x100000 Kernel panic - not syncing: Cannot allocate trampoline
Pid: 0, comm: swapper Tainted: G W 3.2.44 #7 Call Trace: [<c12245eb>] ? panic+0x57/0x12a [<c12f77e7>] ? setup_trampolines+0x40/0xb1 [<c12f51df>] ? setup_arch+0x565/0x9dd [<c12f3421>] ? start_kernel+0x5e/0x275
Check the kernel source to find out what the constraints are for that trampoline allocation. Maybe it must be in some region where there isn't any available RAM, which would be a bug in the memory map for this (and more?) mainboards.
The crux of the problem is the following. 0 -> 64MiB is set to be uncacheable. The message from the kernel about 63MiB is because the fixed mtrrs cover the first meg. I'm not sure where the memory controller messages reside in the original log but if there is memory there ensure it is added as cacheable memory resource.
MTRR: Physical address space: 0x0000000000000000 - 0x0000000004000000 size 0x04000000 type 0 0x0000000004000000 - 0x000000001e000000 size 0x1a000000 type 6 0x000000001e000000 - 0x0000000100000000 size 0xe2000000 type 0 MTRR: Fixed MSR 0x250 0x0000000000000000 MTRR: Fixed MSR 0x258 0x0000000000000000 MTRR: Fixed MSR 0x259 0x0000000000000000 MTRR: Fixed MSR 0x268 0x0000000000000000 MTRR: Fixed MSR 0x269 0x0000000000000000 MTRR: Fixed MSR 0x26a 0x0000000000000000 MTRR: Fixed MSR 0x26b 0x0000000000000000 MTRR: Fixed MSR 0x26c 0x0000000000000000 MTRR: Fixed MSR 0x26d 0x0000000000000000 MTRR: Fixed MSR 0x26e 0x0000000000000000 MTRR: Fixed MSR 0x26f 0x0000000000000000 call enable_fixed_mtrr() CPU physical address size: 32 bits MTRR: default type WB/UC MTRR counts: 5/4. MTRR: UC selected as default type. MTRR: 0 base 0x0000000004000000 mask 0x00000000fc000000 type 6 MTRR: 1 base 0x0000000008000000 mask 0x00000000f8000000 type 6 MTRR: 2 base 0x0000000010000000 mask 0x00000000f0000000 type 6 MTRR: 3 base 0x000000001e000000 mask 0x00000000fe000000 type 0