linux-kernel - Re: 3.10-rc4: mtrr_cleanup: can not find optimal value, please specify mtrr_gran_size/mtrr_chunk

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives
Hash Suite: Windows password security audit tool. GUI, reports in PDF.
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date:	Mon, 10 Jun 2013 11:28:15 -0700
From:	Yinghai Lu <yinghai@...nel.org>
To:	Sergey Meirovich <rathamahata@...il.com>
Cc:	Matt <jackdachef@...il.com>,
	Linux Kernel <linux-kernel@...r.kernel.org>
Subject: Re: 3.10-rc4: mtrr_cleanup: can not find optimal value, please
 specify mtrr_gran_size/mtrr_chunk_size

On Mon, Jun 10, 2013 at 11:00 AM, Sergey Meirovich
<rathamahata@...il.com> wrote:

> 3.10-rc5 with patches has curred error messages in dmesg but MTRRs
> still do not cover my entire memory (7748Mb) or anything close to it
> ("total RAM covered: 2936M").Unfortunately, I don't have anything
> other to compare to because this system started straight with 3.9.X

Your system is AMD 64bit, so there is TOM2.

>
> rathamahata@...edriver ~ $ free -m
>              total       used       free     shared    buffers     cached
> Mem:          7748       1264       6483          0         56        513
> -/+ buffers/cache:        695       7053
> Swap:         3659          0       3659
> rathamahata@...edriver ~ $
>
> ...
> [    0.000000] e820: last_pfn = 0x23f000 max_arch_pfn = 0x400000000
> [    0.000000] MTRR default type: uncachable
> [    0.000000] MTRR fixed ranges enabled:
> [    0.000000]   00000-9FFFF write-back
> [    0.000000]   A0000-BFFFF write-through
> [    0.000000]   C0000-D2FFF write-protect
> [    0.000000]   D3000-DFFFF uncachable
> [    0.000000]   E0000-FFFFF write-protect
> [    0.000000] MTRR variable ranges enabled:
> [    0.000000]   0 base 000000000000 mask FFFF80000000 write-back
> [    0.000000]   1 base 000080000000 mask FFFFC0000000 write-back
> [    0.000000]   2 base 0000B7800000 mask FFFFFF800000 uncachable
> [    0.000000]   3 base 0000B8000000 mask FFFFF8000000 uncachable
> [    0.000000]   4 disabled
> [    0.000000]   5 disabled
> [    0.000000]   6 disabled
> [    0.000000]   7 disabled
> [    0.000000] TOM2: 000000023f000000 aka 9200M
> [    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> [    0.000000] original variable MTRRs
> [    0.000000] reg 0, base: 0GB, range: 2GB, type WB
> [    0.000000] reg 1, base: 2GB, range: 1GB, type WB
> [    0.000000] reg 2, base: 2936MB, range: 8MB, type UC
> [    0.000000] reg 3, base: 2944MB, range: 128MB, type UC
> [    0.000000] total RAM covered: 2936M
> [    0.000000] Found optimal setting for mtrr clean up
> [    0.000000]  gran_size: 64K  chunk_size: 256M        num_reg: 4
>  lose cover RAM: 0G
> [    0.000000] New variable MTRRs
> [    0.000000] reg 0, base: 0GB, range: 2GB, type WB
> [    0.000000] reg 1, base: 2GB, range: 1GB, type WB
> [    0.000000] reg 2, base: 2936MB, range: 8MB, type UC
> [    0.000000] reg 3, base: 2944MB, range: 128MB, type UC
> [    0.000000] e820: update [mem 0xb7800000-0xffffffff] usable ==> reserved
> [    0.000000] e820: last_pfn = 0xb7800 max_arch_pfn = 0x400000000
> [    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576
> [    0.000000] Using GB pages for direct mapping
> [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]20:
> last_pfn = 0x23f000 max_arch_pfn = 0x400000000
> [    0.000000] MTRR default type: uncachable
> [    0.000000] MTRR fixed ranges enabled:
> [    0.000000]   00000-9FFFF write-back
> [    0.000000]   A0000-BFFFF write-through
> [    0.000000]   C0000-D2FFF write-protect
> [    0.000000]   D3000-DFFFF uncachable
> [    0.000000]   E0000-FFFFF write-protect
> [    0.000000] MTRR variable ranges enabled:
> [    0.000000]   0 base 000000000000 mask FFFF80000000 write-back
> [    0.000000]   1 base 000080000000 mask FFFFC0000000 write-back
> [    0.000000]   2 base 0000B7800000 mask FFFFFF800000 uncachable
> [    0.000000]   3 base 0000B8000000 mask FFFFF8000000 uncachable
> [    0.000000]   4 disabled
> [    0.000000]   5 disabled
> [    0.000000]   6 disabled
> [    0.000000]   7 disabled
> [    0.000000] TOM2: 000000023f000000 aka 9200M

[4G, 9200M) is write-back automatically, there is no need to cover them
again with VAR mtrr.

> [    0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
> [    0.000000] original variable MTRRs
> [    0.000000] reg 0, base: 0GB, range: 2GB, type WB
> [    0.000000] reg 1, base: 2GB, range: 1GB, type WB
> [    0.000000] reg 2, base: 2936MB, range: 8MB, type UC
> [    0.000000] reg 3, base: 2944MB, range: 128MB, type UC
> [    0.000000] total RAM covered: 2936M

It only count var really.

> [    0.000000] Found optimal setting for mtrr clean up
> [    0.000000]  gran_size: 64K  chunk_size: 256M        num_reg: 4
>  lose cover RAM: 0G
> [    0.000000] New variable MTRRs
> [    0.000000] reg 0, base: 0GB, range: 2GB, type WB
> [    0.000000] reg 1, base: 2GB, range: 1GB, type WB
> [    0.000000] reg 2, base: 2936MB, range: 8MB, type UC
> [    0.000000] reg 3, base: 2944MB, range: 128MB, type UC
> [    0.000000] e820: update [mem 0xb7800000-0xffffffff] usable ==> reserved
> [    0.000000] e820: last_pfn = 0xb7800 max_arch_pfn = 0x400000000
> [    0.000000] Base memory trampoline at [ffff880000099000] 99000 size 24576
> [    0.000000] Using GB pages for direct mapping
> [    0.000000] init_memory_mapping: [mem 0x00000000-0x000fffff]
> ...

so there is no problem with your system...

Thanks

Yinghai
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/