| View previous topic :: View next topic |
| Author |
Message |
equaeghe
Apprentice
Joined: 22 Feb 2005
Posts: 258
|
 Posted: Tue Jan 24, 2012 8:33 am Post subject: [workaround] MTRR allocation failed. [...] |
 |
|
Hi,
I have a Sandy Bridge ThinkPad X220 with 8GB of ram and use the i915 graphics driver. [EDIT: I enable KMS, which is working.]
While perusing my logs, I encountered:
| Code: |
# grep MTRR /var/log/everything/current
[kernel] [ 0.768627] mtrr: no more MTRRs available
[kernel] [ 0.768728] [drm] MTRR allocation failed. Graphics performance may suffer.
|
[EDIT: With dmesg, I additionally find:
| Code: |
[ 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-FFFFF write-protect
[ 0.000000] MTRR variable ranges enabled:
[ 0.000000] 0 base 0FFC00000 mask FFFC00000 write-protect
[ 0.000000] 1 base 000000000 mask F80000000 write-back
[ 0.000000] 2 base 080000000 mask FC0000000 write-back
[ 0.000000] 3 base 0C0000000 mask FE0000000 write-back
[ 0.000000] 4 base 0DC000000 mask FFC000000 uncachable
[ 0.000000] 5 base 0DB000000 mask FFF000000 uncachable
[ 0.000000] 6 base 100000000 mask F00000000 write-back
[ 0.000000] 7 base 200000000 mask FE0000000 write-back
[ 0.000000] 8 base 21F000000 mask FFF000000 uncachable
[ 0.000000] 9 base 21E800000 mask FFF800000 uncachable
|
]
Looking at the MTRR's, I got:
| Code: |
# cat /proc/mtrr
reg00: base=0x0ffc00000 ( 4092MB), size= 4MB, count=1: write-protect
reg01: base=0x000000000 ( 0MB), size= 2048MB, count=1: write-back
reg02: base=0x080000000 ( 2048MB), size= 1024MB, count=1: write-back
reg03: base=0x0c0000000 ( 3072MB), size= 512MB, count=1: write-back
reg04: base=0x0dc000000 ( 3520MB), size= 64MB, count=1: uncachable
reg05: base=0x0db000000 ( 3504MB), size= 16MB, count=1: uncachable
reg06: base=0x100000000 ( 4096MB), size= 4096MB, count=1: write-back
reg07: base=0x200000000 ( 8192MB), size= 512MB, count=1: write-back
reg08: base=0x21f000000 ( 8688MB), size= 16MB, count=1: uncachable
reg09: base=0x21e800000 ( 8680MB), size= 8MB, count=1: uncachable
|
I don't know how to interpret/work with this, but it does look rather messy; in other forums, the number of MTRRs goes up to at most 8.
From other forum posts, I gathered that the kernel can be configured to clean up MTRRs, but this is already done:
| Code: |
# grep MTRR /usr/src/linux/.config
CONFIG_MTRR=y
CONFIG_MTRR_SANITIZER=y
CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1
CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1
# grep X86_PAT /usr/src/linux/.config
CONFIG_X86_PAT=y
|
What further steps can I take? Is further diagnosis needed.
(The laptop is working fine, but if I can get better graphics performance, I would of course like to.)
N.B.: The only other non-successful graphics-related message in my logs is:
| Code: |
# grep "AGP bridge" /var/log/everything/current
Jan 24 08:47:36 [kernel] [ 0.000000] No AGP bridge found
Jan 24 08:47:36 [kernel] [ 0.000000] No AGP bridge found
|
EDIT:
Last edited by equaeghe on Fri Feb 17, 2012 10:00 pm; edited 4 times in total |
|
| Back to top |
|
 |
aCOSwt
Advocate
Joined: 19 Oct 2007
Posts: 2035
Location: Between the keyboard and the chair
|
| Posted: Tue Jan 24, 2012 9:18 am Post subject: |
|
|
Did you request write-combining (mtrr:3) as part of your boot command line ?
(I use lilo and set this line : | Code: | | append="video=vesafb:mtrr:3,ywrap" |
)
_________________
In theory there are no differences between theory and practice. In practice, there are.
Don't try to understand my posts. Immanuel Kant never did, he thinks that only music and laughter do not have to mean anything. |
|
| Back to top |
|
|
equaeghe
Apprentice
Joined: 22 Feb 2005
Posts: 258
|
| Posted: Tue Jan 24, 2012 10:04 am Post subject: |
|
|
| aCOSwt wrote: | Did you request write-combining (mtrr:3) as part of your boot command line ?
|
No, I use KMS, which requires no fb driver, so I don't use vesafb. |
|
| Back to top |
|
|
Gusar
Advocate
Joined: 09 Apr 2005
Posts: 2553
Location: Slovenia
|
| Posted: Tue Jan 24, 2012 12:31 pm Post subject: |
|
|
Ignore the message. If your processor has PAT (and it probably does), it'll be used instead of MTRR.
If you want to give it a test, boot with nopat on the kernel line in grub.conf. |
|
| Back to top |
|
|
equaeghe
Apprentice
Joined: 22 Feb 2005
Posts: 258
|
| Posted: Tue Jan 24, 2012 12:44 pm Post subject: |
|
|
| Gusar wrote: | | Ignore the message. If your processor has PAT (and it probably does), it'll be used instead of MTRR. |
PAT is enabled on my system, however, as far as I've understood, MTRR stuff needs to be in order anyway.
My understanding is based on:
From http://en.gentoo-wiki.com/wiki/MTRR:
| Quote: |
PAT Support Is a new type of memory type register which works with MTRR it works NOT as a MTRR but instead allows faster more flexible way in partitioning memory resources. Note PAT does not allocate the memory resources like MTRR does but takes control of the memory inside of what the MTRR has allocated. A fair statement would be to say for a system supporting MTRR and PAT would be: MTRR creates the memory mapping and PAT manages the tables inside of them.
|
From /usr/src/linux/Documentation/x86/pat.txt:
| Quote: |
x86 Page Attribute Table (PAT) allows for setting the memory attribute at the
page level granularity. PAT is complementary to the MTRR settings which allows
for setting of memory types over physical address ranges. However, PAT is
more flexible than MTRR due to its capability to set attributes at page level
and also due to the fact that there are no hardware limitations on number of
such attribute settings allowed. Added flexibility comes with guidelines for
not having memory type aliasing for the same physical memory with multiple
virtual addresses.
|
|
|
| Back to top |
|
|
Gusar
Advocate
Joined: 09 Apr 2005
Posts: 2553
Location: Slovenia
|
| Posted: Tue Jan 24, 2012 2:10 pm Post subject: |
|
|
| Did you do the test with nopat? I did once on my netbook. After I saw the results, I stopped caring that I have messed up MTRRs. |
|
| Back to top |
|
|
equaeghe
Apprentice
Joined: 22 Feb 2005
Posts: 258
|
| Posted: Tue Jan 24, 2012 3:00 pm Post subject: |
|
|
| Gusar wrote: | | Did you do the test with nopat? I did once on my netbook. After I saw the results, I stopped caring that I have messed up MTRRs. |
Yes, I am currently running with nopat. There is no noticeable difference in speed/graphics responsiveness.
I will report back if I do notice a difference.
Perhaps this means PAT has no (beneficial) effect on my system because my MTRRs are not set up as they should. |
|
| Back to top |
|
|
Gusar
Advocate
Joined: 09 Apr 2005
Posts: 2553
Location: Slovenia
|
| Posted: Tue Jan 24, 2012 3:34 pm Post subject: |
|
|
| equaeghe wrote: | | Perhaps this means PAT has no (beneficial) effect on my system because my MTRRs are not set up as they should. |
Or perhaps it means that despite screwed up MTRRs, they're still good enough? Do you actually notice any issues, or did you just see the error message? |
|
| Back to top |
|
|
equaeghe
Apprentice
Joined: 22 Feb 2005
Posts: 258
|
| Posted: Tue Jan 24, 2012 3:47 pm Post subject: |
|
|
| Gusar wrote: | | Do you actually notice any issues, or did you just see the error message? |
My graphics is stable; speed/responsiveness seems decent when comparing to a 6 year old laptop.
The error message is quite clear:
| Quote: |
# grep MTRR /var/log/everything/current
[kernel] [ 0.768627] mtrr: no more MTRRs available
[kernel] [ 0.768728] [drm] MTRR allocation failed. Graphics performance may suffer.
|
drm tries to allocate an MTRR for the benefit of the graphics subsystem, but it can't, which has an unknown impact on the graphics performance.
The only way I am able to judge whether this impact is important or not is to fix my MTRR setup and make the comparison. As your experience with PAT showed, these setting may have an important impact. Currently, assuming that I will gain nothing by fixing my MTRR setup is just speculation. |
|
| Back to top |
|
|
equaeghe
Apprentice
Joined: 22 Feb 2005
Posts: 258
|
| Posted: Fri Feb 17, 2012 9:59 pm Post subject: |
|
|
The following workaround is available:
https://lkml.org/lkml/2011/9/9/424
* build drm as a module and not in the kernel (unimportant esthetical downside: nice framebuffer second or two later in the booting process)
* disable the MTRR write-protect entry that currently precludes automatic MTRR rewriting right before loading the drm module; i.e., in /etc/modprobe.d/drm.conf put (in my case):
| Code: | install drm (echo "disable=0" > /proc/mtrr); /sbin/modprobe --ignore-install drm $CMDLINE_OPTS
|
Perhaps the MTRR cleanup routine will be able to deal with write-protect entries in the future... |
|
| Back to top |
|
|
|
|
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
|
|
Kernel & Hardware
