Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
MTRR allocation not optimal
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware
View previous topic :: View next topic  
Author Message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 5822
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Thu Jun 06, 2013 9:55 pm    Post subject: MTRR allocation not optimal Reply with quote

Hi guys,

I'm getting the following error message in dmesg at boot:

mtrr_cleanup: can not find optimal value
please specify mtrr_gran_size/mtrr_chunk_size


http://pastebin.com/sJqqhaRg


when specifying any settings it still fails and continues in searching gran_size, chunk_size but is not successful


Quote:
cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 8192MB, count=1: write-back
reg01: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-back
reg02: base=0x0c0000000 ( 3072MB), size= 1024MB, count=1: uncachable


any ideas on how to "fix" this ?



Many thanks in advance :)



edit:

does it even play a role when PAT is enabled ?
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.5.2

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Thu Jun 06, 2013 10:21 pm    Post subject: Reply with quote

Are you running a 3.10-rc?

If yes then... all I can tell right now is that... you are not alone ! :D

BTW... lose cover RAM: -0G... that looks quite odd.
_________________
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 5822
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Thu Jun 06, 2013 10:37 pm    Post subject: Reply with quote

aCOSwt wrote:
Are you running a 3.10-rc?

If yes then... all I can tell right now is that... you are not alone ! :D

BTW... lose cover RAM: -0G... that looks quite odd.


haha - yeah :mrgreen:


yes, that looks weird :?

some miscalculation, kernel bug, issues on my box - no idea :(


just looked through kernel log and I'm not 100% sure but it didn't seem to have existed with rc3

I'm running latest upstream sources - so it must be a regression
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.5.2

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Sun Jun 09, 2013 9:44 am    Post subject: Reply with quote

2011: http://lkml.indiana.edu/hypermail/linux/kernel/1106.0/01263.html

Some discussion: http://my-fuzzy-logic.de/blog/index.php?/archives/41-Solving-linux-MTRR-problems.html

MTRRs and PATs (page attribute tables), a little clarity:
https://patchwork.kernel.org/patch/1424661/
_________________
TIA
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 5822
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sun Jun 09, 2013 12:50 pm    Post subject: Reply with quote

thanks for those links !


the (supposedly) optimal settings for my system are:

Code:
cat /usr/src/mtrr_proc-mtrr_3.8.13.txt
reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg03: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-back
reg04: base=0x0d0000000 ( 3328MB), size=  256MB, count=1: write-combining



I wrote a simple bash-script which I'll launch via an init script on boot

but beforehand I'd like to know your opinion whether it's correct:

Code:
#!/bin/sh

echo "disable=5" > /proc/mtrr
echo "disable=4" > /proc/mtrr
echo "disable=3" > /proc/mtrr
echo "disable=2" > /proc/mtrr
echo "disable=1" > /proc/mtrr
echo "disable=0" > /proc/mtrr

echo "base=0x0 size=0x80000000 type=write-back" > /proc/mtrr
echo "base=0x80000000 size=0x40000000 type=write-back" > /proc/mtrr
echo "base=0x100000000 size=0x100000000 type=write-back" > /proc/mtrr
echo "base=0x200000000 size=0x40000000 type=write-back" > /proc/mtrr
echo "base=0x0d0000000 size=0x010000000 type=write-combining" > /proc/mtrr



is

Code:
echo "disable=5" > /proc/mtrr
echo "disable=4" > /proc/mtrr
echo "disable=3" > /proc/mtrr
echo "disable=2" > /proc/mtrr
echo "disable=1" > /proc/mtrr
echo "disable=0" > /proc/mtrr


the correct order ?

or would be

Code:
echo "disable=0" > /proc/mtrr
echo "disable=1" > /proc/mtrr
echo "disable=2" > /proc/mtrr
echo "disable=3" > /proc/mtrr
echo "disable=4" > /proc/mtrr
echo "disable=5" > /proc/mtrr


better ? - if yes - what is "better" in this context ?


edit:

I've read on the net that the order "matters" - hm, ok

but in what connection ?

from higher ranges to lower ones ?

edit.




I'm getting several of the following messages when attempting to run the script successfully:

Quote:
bash: echo: write error: Invalid argument


the result however "seems" OK:

Quote:
cat /proc/mtrr
reg00: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg03: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-back
reg04: base=0x0d0000000 ( 3328MB), size= 256MB, count=1: write-combining


but output of dmesg e.g. says:

Quote:
[ 109.603518] mtrr: MTRR 5 not used
[ 109.604112] mtrr: MTRR 4 not used
[ 109.604403] mtrr: MTRR 3 not used


when running the (modified) script several times:

Quote:
[ 287.193885] mtrr: MTRR 5 not used
[ 287.620787] mtrr: MTRR 0 not used
[ 290.169564] mtrr: MTRR 1 not used
[ 292.783499] mtrr: MTRR 2 not used
[ 295.340769] mtrr: MTRR 3 not used
[ 297.531119] mtrr: MTRR 4 not used
[ 299.739416] mtrr: MTRR 5 not used


what does that mean ?
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.5.2

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 5822
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sun Jun 09, 2013 2:03 pm    Post subject: Reply with quote

continuing the past post:

changing the order indeed make a change:

it now applies the changes without error:

Code:
cat /proc/mtrr
reg00: base=0x000000000 (    0MB), size= 2048MB, count=1: write-back
reg01: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg02: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg03: base=0x200000000 ( 8192MB), size= 1024MB, count=1: write-back
reg04: base=0x0d0000000 ( 3328MB), size=  256MB, count=1: write-combining


mtrr doesn't play a large role anymore (probably little on desktops)

but next time I encounter this on my laptop - it might be helpful


current lkml activity:

[url=[PATCH buf-fix] kernel, range: fix broken mtrr_cleanup] http://marc.info/?l=linux-kernel&m=137077095817521&w=2 [/url]

nice :)
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.5.2

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
aCOSwt
Moderator
Moderator


Joined: 19 Oct 2007
Posts: 2537
Location: Hilbert space

PostPosted: Sun Jun 09, 2013 5:16 pm    Post subject: Reply with quote

kernelOfTruth wrote:
current lkml activity:
[url=[PATCH buf-fix] kernel, range: fix broken mtrr_cleanup] http://marc.info/?l=linux-kernel&m=137077095817521&w=2 [/url]
nice :)

Cool! Thanks for the link kOT!
_________________
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Sun Jun 09, 2013 7:50 pm    Post subject: Reply with quote

I looked in /proc/cpuinfo on a couple of amd systems. They both
have "pat" in flags (athlon X2 and phenom II). I take it that means
"page attribute table" support, which will override mtrr settings in
operation on a page-by-page basis in the page tables (setting acesses
to the page uncached, writeback, writethrough, write-protected,
or write-combining). So I can disable the mtrr_cleanup and forget it
on those systems?

Apparently PAT support was officially added to the kernel in
2.6.26: http://kernelnewbies.org/Linux_2_6_26#head-619b02eadc63322536a5ac956d72ca32035216c3

(I do not really get how PAT is "complementary" to mtrrs, though.
One of the kernel messages says the PAT setting on the page
takes precedence over the mtrr setting for the range that page
is in, so the kernel/cpu must check each page anyway for kernels
that have PAT enabled on cpus that support it.)

edit:
I guess in general it is reasonable to leave the mtrr sanitizer enabled
in case your cpu turns up on a list of "PAT support broken on these
cpu models" when the kernel is setting up page attributes in the
page tables. The worst that can happen is log noise.
_________________
TIA
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 5822
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Sun Jun 09, 2013 9:00 pm    Post subject: Reply with quote

wcg wrote:
I looked in /proc/cpuinfo on a couple of amd systems. They both
have "pat" in flags (athlon X2 and phenom II). I take it that means
"page attribute table" support, which will override mtrr settings in
operation on a page-by-page basis in the page tables (setting acesses
to the page uncached, writeback, writethrough, write-protected,
or write-combining). So I can disable the mtrr_cleanup and forget it
on those systems?

Apparently PAT support was officially added to the kernel in
2.6.26: http://kernelnewbies.org/Linux_2_6_26#head-619b02eadc63322536a5ac956d72ca32035216c3

(I do not really get how PAT is "complementary" to mtrrs, though.
One of the kernel messages says the PAT setting on the page
takes precedence over the mtrr setting for the range that page
is in, so the kernel/cpu must check each page anyway for kernels
that have PAT enabled on cpus that support it.)

edit:
I guess in general it is reasonable to leave the mtrr sanitizer enabled
in case your cpu turns up on a list of "PAT support broken on these
cpu models" when the kernel is setting up page attributes in the
page tables. The worst that can happen is log noise.


thanks !

ok, so it's not obsolete at all - hm :?


https://bugzilla.kernel.org/show_bug.cgi?id=59491

"proper" fix for this issue:

[url="[PATCH 1/2] x86,mtrr: Fix original mtrr range get for mtrr_cleanup"] http://marc.info/?l=linux-kernel&m=137080807327118&w=2 [/url]
[url="[PATCH 2/2] x86, range: make add_range use blank slot"] http://marc.info/?l=linux-kernel&m=137080805927115&w=2 [/url]
_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.5.2

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
wcg
Guru
Guru


Joined: 06 Jan 2009
Posts: 588

PostPosted: Mon Jun 10, 2013 12:29 am    Post subject: Reply with quote

We wish the mtrr sanitizer was obsolete, and for a lot of cpus with
working PAT support it is, but it is not obsolete on all of the systems
that linux might run on, and that is the kicker.

You get somebody with Shorewall running on a pII or a K6 or something,
they do not need the performance of a faster cpu, they probably do not
need the performance of write-combining support for their gpu, but they
do not have working PAT support, so they need usable mtrr ranges, and
the kernel may be better at setting those up than their BIOS.

This closed thread from stackoverflow has a detailed explanation
of what happens for loads and stores in the different caching modes
set up by these "memory type" ranges and page attributes:
http://stackoverflow.com/questions/13297178/how-mtrr-registers-implemented
_________________
TIA
Back to top
View user's profile Send private message
kernelOfTruth
Watchman
Watchman


Joined: 20 Dec 2005
Posts: 5822
Location: Vienna, Austria; Germany; hello world :)

PostPosted: Tue Aug 19, 2014 6:44 pm    Post subject: Reply with quote

thanks for that link, wcg !

ran into that problem again but with my new computer:

Quote:
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 0000000000 mask 7800000000 write-back
[ 0.000000] 1 base 0800000000 mask 7FE0000000 write-back
[ 0.000000] 2 base 00E0000000 mask 7FE0000000 uncachable
[ 0.000000] 3 base 00DC000000 mask 7FFC000000 uncachable
[ 0.000000] 4 base 00DB000000 mask 7FFF000000 uncachable
[ 0.000000] 5 base 081FE00000 mask 7FFFE00000 uncachable
[ 0.000000] 6 disabled
[ 0.000000] 7 disabled
[ 0.000000] 8 disabled
[ 0.000000] 9 disabled
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] original variable MTRRs
[ 0.000000] reg 0, base: 0GB, range: 32GB, type WB
[ 0.000000] reg 1, base: 32GB, range: 512MB, type WB
[ 0.000000] reg 2, base: 3584MB, range: 512MB, type UC
[ 0.000000] reg 3, base: 3520MB, range: 64MB, type UC
[ 0.000000] reg 4, base: 3504MB, range: 16MB, type UC
[ 0.000000] reg 5, base: 33278MB, range: 2MB, type UC
[ 0.000000] total RAM covered: 32686M
[ 0.000000] gran_size: 64K chunk_size: 64K num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 64K chunk_size: 128K num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 64K chunk_size: 256K num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 64K chunk_size: 512K num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 64K chunk_size: 1M num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 64K chunk_size: 2M num_reg: 10 lose cover RAM: 254M
[ 0.000000] *BAD*gran_size: 64K chunk_size: 4M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 64K chunk_size: 8M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 64K chunk_size: 16M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 64K chunk_size: 32M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 64K chunk_size: 64M num_reg: 10 lose cover RAM: -2M
[ 0.000000] gran_size: 64K chunk_size: 128M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 64K chunk_size: 256M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 64K chunk_size: 512M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 64K chunk_size: 1G num_reg: 10 lose cover RAM: 0G
[ 0.000000] *BAD*gran_size: 64K chunk_size: 2G num_reg: 10 lose cover RAM: -1G
[ 0.000000] gran_size: 128K chunk_size: 128K num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 128K chunk_size: 256K num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 128K chunk_size: 512K num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 128K chunk_size: 1M num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 128K chunk_size: 2M num_reg: 10 lose cover RAM: 254M
[ 0.000000] *BAD*gran_size: 128K chunk_size: 4M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 128K chunk_size: 8M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 128K chunk_size: 16M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 128K chunk_size: 32M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 128K chunk_size: 64M num_reg: 10 lose cover RAM: -2M
[ 0.000000] gran_size: 128K chunk_size: 128M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 128K chunk_size: 256M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 128K chunk_size: 512M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 128K chunk_size: 1G num_reg: 10 lose cover RAM: 0G
[ 0.000000] *BAD*gran_size: 128K chunk_size: 2G num_reg: 10 lose cover RAM: -1G
[ 0.000000] gran_size: 256K chunk_size: 256K num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 256K chunk_size: 512K num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 256K chunk_size: 1M num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 256K chunk_size: 2M num_reg: 10 lose cover RAM: 254M
[ 0.000000] *BAD*gran_size: 256K chunk_size: 4M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 256K chunk_size: 8M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 256K chunk_size: 16M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 256K chunk_size: 32M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 256K chunk_size: 64M num_reg: 10 lose cover RAM: -2M
[ 0.000000] gran_size: 256K chunk_size: 128M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 256K chunk_size: 256M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 256K chunk_size: 512M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 256K chunk_size: 1G num_reg: 10 lose cover RAM: 0G
[ 0.000000] *BAD*gran_size: 256K chunk_size: 2G num_reg: 10 lose cover RAM: -1G
[ 0.000000] gran_size: 512K chunk_size: 512K num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 512K chunk_size: 1M num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 512K chunk_size: 2M num_reg: 10 lose cover RAM: 254M
[ 0.000000] *BAD*gran_size: 512K chunk_size: 4M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 512K chunk_size: 8M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 512K chunk_size: 16M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 512K chunk_size: 32M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 512K chunk_size: 64M num_reg: 10 lose cover RAM: -2M
[ 0.000000] gran_size: 512K chunk_size: 128M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 512K chunk_size: 256M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 512K chunk_size: 512M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 512K chunk_size: 1G num_reg: 10 lose cover RAM: 0G
[ 0.000000] *BAD*gran_size: 512K chunk_size: 2G num_reg: 10 lose cover RAM: -1G
[ 0.000000] gran_size: 1M chunk_size: 1M num_reg: 10 lose cover RAM: 254M
[ 0.000000] gran_size: 1M chunk_size: 2M num_reg: 10 lose cover RAM: 254M
[ 0.000000] *BAD*gran_size: 1M chunk_size: 4M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 1M chunk_size: 8M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 1M chunk_size: 16M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 1M chunk_size: 32M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 1M chunk_size: 64M num_reg: 10 lose cover RAM: -2M
[ 0.000000] gran_size: 1M chunk_size: 128M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 1M chunk_size: 256M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 1M chunk_size: 512M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 1M chunk_size: 1G num_reg: 10 lose cover RAM: 0G
[ 0.000000] *BAD*gran_size: 1M chunk_size: 2G num_reg: 10 lose cover RAM: -1G
[ 0.000000] gran_size: 2M chunk_size: 2M num_reg: 10 lose cover RAM: 254M
[ 0.000000] *BAD*gran_size: 2M chunk_size: 4M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 2M chunk_size: 8M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 2M chunk_size: 16M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 2M chunk_size: 32M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 2M chunk_size: 64M num_reg: 10 lose cover RAM: -2M
[ 0.000000] gran_size: 2M chunk_size: 128M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 2M chunk_size: 256M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 2M chunk_size: 512M num_reg: 10 lose cover RAM: 0G
[ 0.000000] gran_size: 2M chunk_size: 1G num_reg: 10 lose cover RAM: 0G
[ 0.000000] *BAD*gran_size: 2M chunk_size: 2G num_reg: 10 lose cover RAM: -1G
[ 0.000000] gran_size: 4M chunk_size: 4M num_reg: 10 lose cover RAM: 254M
[ 0.000000] *BAD*gran_size: 4M chunk_size: 8M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 4M chunk_size: 16M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 4M chunk_size: 32M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 4M chunk_size: 64M num_reg: 10 lose cover RAM: -2M
[ 0.000000] gran_size: 4M chunk_size: 128M num_reg: 10 lose cover RAM: 2M
[ 0.000000] gran_size: 4M chunk_size: 256M num_reg: 10 lose cover RAM: 2M
[ 0.000000] gran_size: 4M chunk_size: 512M num_reg: 10 lose cover RAM: 2M
[ 0.000000] gran_size: 4M chunk_size: 1G num_reg: 10 lose cover RAM: 2M
[ 0.000000] *BAD*gran_size: 4M chunk_size: 2G num_reg: 10 lose cover RAM: -1022M
[ 0.000000] gran_size: 8M chunk_size: 8M num_reg: 10 lose cover RAM: 254M
[ 0.000000] *BAD*gran_size: 8M chunk_size: 16M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 8M chunk_size: 32M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 8M chunk_size: 64M num_reg: 10 lose cover RAM: -2M
[ 0.000000] gran_size: 8M chunk_size: 128M num_reg: 10 lose cover RAM: 6M
[ 0.000000] gran_size: 8M chunk_size: 256M num_reg: 10 lose cover RAM: 6M
[ 0.000000] gran_size: 8M chunk_size: 512M num_reg: 10 lose cover RAM: 6M
[ 0.000000] gran_size: 8M chunk_size: 1G num_reg: 10 lose cover RAM: 6M
[ 0.000000] *BAD*gran_size: 8M chunk_size: 2G num_reg: 10 lose cover RAM: -1018M
[ 0.000000] gran_size: 16M chunk_size: 16M num_reg: 10 lose cover RAM: 254M
[ 0.000000] *BAD*gran_size: 16M chunk_size: 32M num_reg: 10 lose cover RAM: -2M
[ 0.000000] *BAD*gran_size: 16M chunk_size: 64M num_reg: 10 lose cover RAM: -2M
[ 0.000000] gran_size: 16M chunk_size: 128M num_reg: 10 lose cover RAM: 14M
[ 0.000000] gran_size: 16M chunk_size: 256M num_reg: 10 lose cover RAM: 14M
[ 0.000000] gran_size: 16M chunk_size: 512M num_reg: 10 lose cover RAM: 14M
[ 0.000000] gran_size: 16M chunk_size: 1G num_reg: 10 lose cover RAM: 14M
[ 0.000000] *BAD*gran_size: 16M chunk_size: 2G num_reg: 10 lose cover RAM: -1010M
[ 0.000000] gran_size: 32M chunk_size: 32M num_reg: 10 lose cover RAM: 142M
[ 0.000000] gran_size: 32M chunk_size: 64M num_reg: 10 lose cover RAM: 14M
[ 0.000000] gran_size: 32M chunk_size: 128M num_reg: 10 lose cover RAM: 46M
[ 0.000000] gran_size: 32M chunk_size: 256M num_reg: 10 lose cover RAM: 46M
[ 0.000000] gran_size: 32M chunk_size: 512M num_reg: 10 lose cover RAM: 46M
[ 0.000000] gran_size: 32M chunk_size: 1G num_reg: 10 lose cover RAM: 46M
[ 0.000000] *BAD*gran_size: 32M chunk_size: 2G num_reg: 10 lose cover RAM: -978M
[ 0.000000] gran_size: 64M chunk_size: 64M num_reg: 10 lose cover RAM: 110M
[ 0.000000] gran_size: 64M chunk_size: 128M num_reg: 9 lose cover RAM: 110M
[ 0.000000] gran_size: 64M chunk_size: 256M num_reg: 9 lose cover RAM: 110M
[ 0.000000] gran_size: 64M chunk_size: 512M num_reg: 9 lose cover RAM: 110M
[ 0.000000] gran_size: 64M chunk_size: 1G num_reg: 9 lose cover RAM: 110M
[ 0.000000] gran_size: 64M chunk_size: 2G num_reg: 10 lose cover RAM: 110M
[ 0.000000] gran_size: 128M chunk_size: 128M num_reg: 9 lose cover RAM: 174M
[ 0.000000] gran_size: 128M chunk_size: 256M num_reg: 9 lose cover RAM: 174M
[ 0.000000] gran_size: 128M chunk_size: 512M num_reg: 9 lose cover RAM: 174M
[ 0.000000] gran_size: 128M chunk_size: 1G num_reg: 9 lose cover RAM: 174M
[ 0.000000] gran_size: 128M chunk_size: 2G num_reg: 10 lose cover RAM: 174M
[ 0.000000] gran_size: 256M chunk_size: 256M num_reg: 7 lose cover RAM: 430M
[ 0.000000] gran_size: 256M chunk_size: 512M num_reg: 9 lose cover RAM: 430M
[ 0.000000] gran_size: 256M chunk_size: 1G num_reg: 9 lose cover RAM: 430M
[ 0.000000] gran_size: 256M chunk_size: 2G num_reg: 10 lose cover RAM: 430M
[ 0.000000] gran_size: 512M chunk_size: 512M num_reg: 5 lose cover RAM: 942M
[ 0.000000] gran_size: 512M chunk_size: 1G num_reg: 5 lose cover RAM: 942M
[ 0.000000] gran_size: 512M chunk_size: 2G num_reg: 5 lose cover RAM: 942M
[ 0.000000] gran_size: 1G chunk_size: 1G num_reg: 5 lose cover RAM: 942M
[ 0.000000] gran_size: 1G chunk_size: 2G num_reg: 5 lose cover RAM: 942M
[ 0.000000] gran_size: 2G chunk_size: 2G num_reg: 4 lose cover RAM: 1966M
[ 0.000000] mtrr_cleanup: can not find optimal value
[ 0.000000] please specify mtrr_gran_size/mtrr_chunk_size


stupid :(

edit:

hm, seems that it got fixed while switching from the iGPU to the nvidia card (also had graphical lockups during usage)

optimal settings now are (at least for this boot):

Quote:
[ 0.000000] MTRR default type: uncachable
[ 0.000000] MTRR fixed ranges enabled:
[ 0.000000] 00000-9FFFF write-back
[ 0.000000] A0000-BFFFF uncachable
[ 0.000000] C0000-CFFFF write-protect
[ 0.000000] D0000-DFFFF uncachable
[ 0.000000] E0000-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 0000000000 mask 7800000000 write-back
[ 0.000000] 1 base 0800000000 mask 7FF0000000 write-back
[ 0.000000] 2 base 0810000000 mask 7FF8000000 write-back
[ 0.000000] 3 base 0818000000 mask 7FFC000000 write-back
[ 0.000000] 4 base 081C000000 mask 7FFE000000 write-back
[ 0.000000] 5 base 081E000000 mask 7FFF000000 write-back
[ 0.000000] 6 base 00E0000000 mask 7FE0000000 uncachable
[ 0.000000] 7 disabled
[ 0.000000] 8 disabled
[ 0.000000] 9 disabled
[ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106
[ 0.000000] original variable MTRRs
[ 0.000000] reg 0, base: 0GB, range: 32GB, type WB
[ 0.000000] reg 1, base: 32GB, range: 256MB, type WB
[ 0.000000] reg 2, base: 33024MB, range: 128MB, type WB
[ 0.000000] reg 3, base: 33152MB, range: 64MB, type WB
[ 0.000000] reg 4, base: 33216MB, range: 32MB, type WB
[ 0.000000] reg 5, base: 33248MB, range: 16MB, type WB
[ 0.000000] reg 6, base: 3584MB, range: 512MB, type UC
[ 0.000000] total RAM covered: 32752M
[ 0.000000] Found optimal setting for mtrr clean up
[ 0.000000] gran_size: 64K chunk_size: 32M num_reg: 8 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: 3GB, range: 512MB, type WB
[ 0.000000] reg 3, base: 4GB, range: 4GB, type WB
[ 0.000000] reg 4, base: 8GB, range: 8GB, type WB
[ 0.000000] reg 5, base: 16GB, range: 16GB, type WB
[ 0.000000] reg 6, base: 32GB, range: 512MB, type WB
[ 0.000000] reg 7, base: 33264MB, range: 16MB, type UC
[ 0.000000] e820: update [mem 0xe0000000-0xffffffff] usable ==> reserved
[ 0.000000] e820: last_pfn = 0xdf000 max_arch_pfn = 0x400000000

_________________
https://github.com/kernelOfTruth/ZFS-for-SystemRescueCD/tree/ZFS-for-SysRescCD-4.5.2

Hardcore Gentoo Linux user since 2004 :D
Back to top
View user's profile Send private message
Yamakuzure
Veteran
Veteran


Joined: 21 Jun 2006
Posts: 1571
Location: Bardowick, Germany

PostPosted: Wed Aug 20, 2014 7:26 am    Post subject: Reply with quote

Just fix it by looking where the best results come out. The best would be "lose cover RAM" to be zero. It must not be negative. If there is no zero result, take the best one with a positive lose.

On my system I have in /etc/default/grub:
Code:
enable_mtrr_cleanup mtrr_spare_reg_nr=1 mtrr_gran_size=32M mtrr_chunk_size=1G
Resulting in a lose cover RAM of 8MB or so. (Must check, after some days uptime dmesg doesn't reach back that far any more...)
_________________
systemd - The biggest fallacies
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Kernel & Hardware All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum