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