This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 584493 - [drm] MTRR allocation failed. Graphics performance may suffer
[drm] MTRR allocation failed. Graphics performance may suffer
Status: CLOSED CURRENTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
19
All Linux
low Severity medium
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-04-21 13:31 EDT by Orion Poplawski
Modified: 2013-04-05 12:43 EDT (History)
18 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-04-05 12:43:54 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)
/var/log/messages (65.22 KB, text/plain)
2010-07-20 17:51 EDT, Orion Poplawski
no flags Details
dmesg output (105.61 KB, text/plain)
2011-10-11 14:45 EDT, Kjartan Maraas
no flags Details
/proc/mtrr output (276 bytes, text/plain)
2011-10-11 14:47 EDT, Kjartan Maraas
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
Linux Kernel 15431 None None None Never
FreeDesktop.org 26850 None None None Never

  None (edit)
Description Orion Poplawski 2010-04-21 13:31:11 EDT
Description of problem:

[drm] Initialized drm 1.1.0 20060810
i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16
i915 0000:00:02.0: setting latency timer to 64
mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining
[drm] MTRR allocation failed.  Graphics performance may suffer.
  alloc irq_desc for 29 on node -1
  alloc kstat_irqs on node -1
i915 0000:00:02.0: irq 29 for MSI/MSI-X
[drm] set up 31M of stolen space
fbcon: inteldrmfb (fb0) is primary device
Console: switching to colour frame buffer device 180x56
fb0: inteldrmfb frame buffer device

Version-Release number of selected component (if applicable):
2.6.32.11-99.fc12.x86_64

Seeing this on three machines:

Latitude E6400:
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)

OptiPlex 330:
00:02.0 VGA compatible controller [0300]: Intel Corporation 82G33/G31 Express Integrated Graphics Controller [8086:29c2] (rev 0a)

Latitude E5400:
00:02.0 VGA compatible controller [0300]: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller [8086:2a42] (rev 07)
Comment 1 Orion Poplawski 2010-05-21 11:02:16 EDT
Also seeing on a Dell Latitude 13 with 2.6.33.4-95.fc13.x86_64:
00:02.0 VGA compatible controller: Intel Corporation Mobile 4 Series Chipset Integrated Graphics Controller (rev 07)
Comment 2 Luis A. Florit 2010-06-20 20:29:18 EDT
I've had this bug in FC11 for more than a year, and I've seen unattended bug reports about this for more than a year.

Today I began to see this also in my fresh FC13 with a completely new computer.

I wonder why we still bother about filling bug reports for Fedora...

Good luck,
L.
Comment 3 Orion Poplawski 2010-07-14 11:31:09 EDT
Possible upstream bug
Comment 4 Orion Poplawski 2010-07-14 11:34:36 EDT
Possible workaround:

enable_mtrr_cleanup mtrr_spare_reg_nr=1

from freedesktop bug report
Comment 5 Luis A. Florit 2010-07-16 19:30:57 EDT
(In reply to comment #4)
> Possible workaround:
> 
> enable_mtrr_cleanup mtrr_spare_reg_nr=1
> 
> from freedesktop bug report    

I'm not sure how to use this suggestion. I added this line to my grub.conf file:

# defoptions=quiet splash enable_mtrr_cleanup mtrr_spare_reg_nr=1

Not sure if it was actually used, but I am getting the same errors.

Thanks,
L.
Comment 6 Luis A. Florit 2010-07-16 19:32:35 EDT
(In reply to comment #5)
> (In reply to comment #4)
> > Possible workaround:
> > 
> > enable_mtrr_cleanup mtrr_spare_reg_nr=1
> > 
> > from freedesktop bug report    
> 
> I'm not sure how to use this suggestion. I added this line to my grub.conf
> file:
> 
> # defoptions=quiet splash enable_mtrr_cleanup mtrr_spare_reg_nr=1
> 
> Not sure if it was actually used, but I am getting the same errors.

The output of dmesg is:

$ dmesg |grep mtrr

mtrr_cleanup: can not find optimal value
please specify mtrr_gran_size/mtrr_chunk_size
mtrr: type mismatch for d0000000,10000000 old: write-back new: write-combining
Comment 7 Orion Poplawski 2010-07-20 17:51:54 EDT
Created attachment 433272 [details]
/var/log/messages

This contains some more info on the mtrr stuff from /var/log/messages.  I get the same:

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

Messages as well.  I tried mtrr_cleanup_debug but that produces so much output that the kernel ring buffer overflows.
Comment 8 Sanjeev Premi 2010-09-04 13:05:19 EDT
I get same error on FC13.

Have tried all other suggestions mentioned so far.
Here are some details - after removing bootargs - that didn't work anyway :(

$ uname -r
2.6.33.6-147.2.4.fc13.x86_64
$
$ dmesg | grep -i mtrr
MTRR default type: uncachable
MTRR fixed ranges enabled:
MTRR variable ranges enabled:
original variable MTRRs
mtrr_cleanup: can not find optimal value
please specify mtrr_gran_size/mtrr_chunk_size
mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining
[drm] MTRR allocation failed.  Graphics performance may suffer.
$
Comment 9 Bug Zapper 2010-11-03 12:37:58 EDT
This message is a reminder that Fedora 12 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 12.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '12'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 12's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 12 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 10 Kjartan Maraas 2010-11-03 16:30:19 EDT
Moving this to F14 since I see it there as well. Also using a Dell. Latitude E4300. I've seen this bug reported against Ubuntu and Arch Linux as well, both cases with Dell hardware.

[kmaraas@e4300 ~]$ dmesg | grep -i mtrr
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000] MTRR variable ranges enabled:
[    0.000000] original variable MTRRs
[    0.000000] mtrr_cleanup: can not find optimal value
[    0.000000] please specify mtrr_gran_size/mtrr_chunk_size
[    1.901280] mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining
[    1.901283] [drm] MTRR allocation failed.  Graphics performance may suffer.

Adding Dave Airlie on Cc: after a suggestion from Owen Taylor that this might cut through the general bugzilla kernel noise :-)
Comment 11 Kjartan Maraas 2010-11-03 16:31:54 EDT
Forgot to mention that this is with:

libdrm-2.4.22-1 
kernel-PAE-2.6.35.6-48.fc14.i686
Comment 12 Rui Matos 2011-03-29 09:14:45 EDT
Still there in 2.6.38.2-8.fc15.i686.PAE on Ironlake hardware.
Comment 13 armando.fella 2011-07-29 10:36:44 EDT
Still there in 2.6.38.8-35.fc15.x86_64 on Lenovo x220 hardware.
Comment 14 Thomas Spura 2011-10-08 16:51:03 EDT
(In reply to comment #13)
> Still there in 2.6.38.8-35.fc15.x86_64 on Lenovo x220 hardware.

Didn't test it on older kernels, but with 2.6.40.6-0.fc15.x86_64 I only get:

$ dmesg |grep -i mtrr
[    0.000000] MTRR default type: uncachable
[    0.000000] MTRR fixed ranges enabled:
[    0.000000] MTRR variable ranges enabled:
Comment 15 Kjartan Maraas 2011-10-10 01:48:22 EDT
Still here in the FC-16 beta:
[kmaraas@e4300 ~]$ dmesg | grep -i mtrr
[    1.999962] mtrr: type mismatch for e0000000,10000000 old: write-back new: write-combining
[    1.999964] [drm] MTRR allocation failed.  Graphics performance may suffer.
[kmaraas@e4300 ~]$ rpm -q kernel-PAE
kernel-PAE-3.1.0-0.rc8.git0.0.fc16.i686
kernel-PAE-3.1.0-0.rc8.git0.1.fc16.i686
kernel-PAE-3.1.0-0.rc9.git0.0.fc16.i686
[kmaraas@e4300 ~]$ rpm -q libdrm
libdrm-2.4.26-1.fc16.i686
Comment 16 Dave Jones 2011-10-11 14:23:10 EDT
Kjartan, can you attach the full output of dmesg, and also cat /proc/mtrr
(with no mtrr related boot command line options).

Given how long this issue has been around, I think we need to get this passed off onto the upstream mtrr maintainer.
Comment 17 Kjartan Maraas 2011-10-11 14:45:22 EDT
Created attachment 527521 [details]
dmesg output

attaching dmesg output
Comment 18 Kjartan Maraas 2011-10-11 14:47:22 EDT
Created attachment 527522 [details]
/proc/mtrr output

output from /proc/mtrr
Comment 19 Kjartan Maraas 2012-02-20 09:28:50 EST
Could this be related to bug #559424 maybe?
Comment 20 Dave Jones 2012-03-22 13:09:00 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 21 Dave Jones 2012-03-22 13:11:54 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 22 Dave Jones 2012-03-22 13:21:35 EDT
[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.
Comment 23 Mariusz Libera 2012-03-22 15:05:39 EDT
Update didn't fix it for me.
Comment 24 Kjartan Maraas 2012-03-25 06:16:27 EDT
Still the same her as well.
Comment 25 Orion Poplawski 2012-06-12 23:56:07 EDT
Still present in 3.3.7-1.fc16.x86_64
Comment 26 Kjartan Maraas 2012-06-13 05:47:22 EDT
And in F17 with 

Linux localhost.localdomain 3.4.0-1.fc17.x86_64 #1 SMP Sun Jun 3 06:35:17 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux
Comment 27 Josh Boyer 2012-06-13 09:13:34 EDT
I'm going to move this to rawhide.

Aside from the scary sounding message, is anyone actually seeing a problem?  This sounds very much like one of those things that has been there forever but doesn't actually cause an issue.
Comment 28 Rui Matos 2012-06-13 09:36:05 EDT
I've seen this since forever as well, so I don't know if things could be better ;-)
Comment 29 Orion Poplawski 2012-06-13 11:23:54 EDT
None of my users have complained of problems, so yes it probably isn't a critical failure - maybe just not as much contigous graphics memory as theoretically possible?  But messages that match *fail* get flagged by logwatch and are as you say scary sounding.
Comment 30 Mariusz Libera 2012-06-16 20:13:56 EDT
(In reply to comment #27)
> Aside from the scary sounding message, is anyone actually seeing a problem? 

For me text scrolling in ttys was horribly slow. But that was kinda fedora specific issue, nothing like that on debian or arch, so I'm not sure it's related.
Today I updated my BIOS and the "performance may suffer" message is gone and text scrolling in ttys is fast again. Now I get this:

[    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-EFFFF write-protect
[    0.000000]   F0000-FFFFF write-combining
[    0.000000] MTRR variable ranges enabled:
[    0.000000]   0 base 000000000 mask F80000000 write-back
[    0.000000]   1 base 080000000 mask FC0000000 write-back
[    0.000000]   2 base 0BD000000 mask FFF000000 uncachable
[    0.000000]   3 base 0BE000000 mask FFE000000 uncachable
[    0.000000]   4 base 0FFC00000 mask FFFC00000 write-protect
[    0.000000]   5 base 100000000 mask FC0000000 write-back
[    0.000000]   6 base 13FE00000 mask FFFE00000 uncachable
[    0.000000]   7 disabled
[    0.000000]   8 disabled
[    0.000000]   9 disabled


and:

[    0.208438] mtrr: your CPUs had inconsistent variable MTRR settings
[    0.208439] mtrr: probably your BIOS does not setup all CPUs.
[    0.208441] mtrr: corrected configuration.

This is Fedora 17 3.4.0-1.fc17.x86_64
Comment 31 Andrea Oliveri 2012-07-25 17:36:54 EDT
I have a Thinkpad T430 with intel HD 4000 and nvidia NVS 4200 and i suffer of the same bug.
I have FC17 updated and i tried the enable_mtrr_cleanup method but obtained no results.
Comment 32 Andrea Oliveri 2012-08-10 18:49:26 EDT
(In reply to comment #31)
> I have a Thinkpad T430 with intel HD 4000 and nvidia NVS 4200 and i suffer
> of the same bug.
> I have FC17 updated and i tried the enable_mtrr_cleanup method but obtained
> no results.

After i updated to 3.4.5-2.fc17.x86_64 the bug disapered
Comment 33 Orion Poplawski 2012-10-13 13:19:10 EDT
Hmm, I still see it with 3.4.11-1.fc16.x86_64, but perhaps it is only fixed in F17.
Comment 34 Fedora End Of Life 2013-04-03 14:42:58 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 19 development cycle.
Changing version to '19'.

(As we did not run this process for some time, it could affect also pre-Fedora 19 development
cycle bugs. We are very sorry. It will help us with cleanup during Fedora 19 End Of Life. Thank you.)

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora19

Note You need to log in before you can comment on or make changes to this bug.