Bug 584493

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)

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.

Possible upstream bug

Possible workaround:

enable_mtrr_cleanup mtrr_spare_reg_nr=1

from freedesktop bug report

(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.

(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

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.

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.
$

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

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 :-)

Forgot to mention that this is with:

libdrm-2.4.22-1 
kernel-PAE-2.6.35.6-48.fc14.i686

Still there in 2.6.38.2-8.fc15.i686.PAE on Ironlake hardware.

Still there in 2.6.38.8-35.fc15.x86_64 on Lenovo x220 hardware.

(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:

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

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.

Created attachment 527521 [details]
dmesg output

attaching dmesg output

Created attachment 527522 [details]
/proc/mtrr output

output from /proc/mtrr

Could this be related to bug #559424 maybe?

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

[mass update]
kernel-3.3.0-4.fc16 has been pushed to the Fedora 16 stable repository.
Please retest with this update.

Update didn't fix it for me.

Still the same her as well.

Still present in 3.3.7-1.fc16.x86_64

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

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.

I've seen this since forever as well, so I don't know if things could be better ;-)

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.

(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

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.

(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

Hmm, I still see it with 3.4.11-1.fc16.x86_64, but perhaps it is only fixed in F17.

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