* mtrr cleanup not doing anything on 2.6.33-rc7 @ 2010-02-10 20:02 Alexander Lam 2010-02-11 1:48 ` Alexander Lam 0 siblings, 1 reply; 5+ messages in thread From: Alexander Lam @ 2010-02-10 20:02 UTC (permalink / raw) To: linux-kernel Hi all, Please CC: me when replying. My kernel config has the following: CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 With previous kernels, dmesg would show that the sanitizer was indeed cleaning up the mtrrs [1] but now, with 2.6.33-rc7 there is no indication that this is occuring, and the intel i915 driver complains: [ 0.613419] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 0.614577] i915 0000:00:02.0: setting latency timer to 64 [ 0.625446] mtrr: no more MTRRs available [ 0.625529] [drm] MTRR allocation failed. Graphics performance may suffer. What has changed and what do I need to do to make the mtrr sanitation work again? [1]: dmesg from previous kernels: [ 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-C7FFF write-protect [ 0.000000] C8000-EFFFF uncachable [ 0.000000] F0000-FFFFF write-protect [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 0FFFE0000 mask 0FFFE0000 write-protect [ 0.000000] 1 base 0FFFC0000 mask 0FFFE0000 uncachable [ 0.000000] 2 base 000000000 mask 0E0000000 write-back [ 0.000000] 3 base 020000000 mask 0E0000000 write-back [ 0.000000] 4 base 03F800000 mask 0FF800000 uncachable [ 0.000000] 5 base 03F600000 mask 0FFE00000 uncachable [ 0.000000] 6 base 03F500000 mask 0FFF00000 uncachable [ 0.000000] 7 base 000000000 mask 0FFFE0000 uncachable [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] original variable MTRRs [ 0.000000] reg 0, base: 4194176KB, range: 128KB, type WP [ 0.000000] reg 1, base: 4194048KB, range: 128KB, type UC [ 0.000000] reg 2, base: 0GB, range: 512MB, type WB [ 0.000000] reg 3, base: 512MB, range: 512MB, type WB [ 0.000000] reg 4, base: 1016MB, range: 8MB, type UC [ 0.000000] reg 5, base: 1014MB, range: 2MB, type UC [ 0.000000] reg 6, base: 1013MB, range: 1MB, type UC [ 0.000000] reg 7, base: 0GB, range: 128KB, type UC [ 0.000000] WARNING: BIOS bug: VAR MTRR 7 contains strange UC entry under 1M, check with your system vendor! [ 0.000000] total RAM coverred: 1013M [ 0.000000] Found optimal setting for mtrr clean up [ 0.000000] gran_size: 64K chunk_size: 16M num_reg: 4 lose cover RAM: 0G [ 0.000000] New variable MTRRs [ 0.000000] reg 0, base: 0GB, range: 1GB, type WB [ 0.000000] reg 1, base: 1013MB, range: 1MB, type UC [ 0.000000] reg 2, base: 1014MB, range: 2MB, type UC [ 0.000000] reg 3, base: 1016MB, range: 8MB, type UC [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 Thanks, -- Alexander Lam ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: mtrr cleanup not doing anything on 2.6.33-rc7 2010-02-10 20:02 mtrr cleanup not doing anything on 2.6.33-rc7 Alexander Lam @ 2010-02-11 1:48 ` Alexander Lam 2010-02-11 10:10 ` Carlos R. Mafra 0 siblings, 1 reply; 5+ messages in thread From: Alexander Lam @ 2010-02-11 1:48 UTC (permalink / raw) To: linux-kernel On Wed, Feb 10, 2010 at 3:02 PM, Alexander Lam <lambchop468@gmail.com> wrote: > > My kernel config has the following: > CONFIG_MTRR=y > CONFIG_MTRR_SANITIZER=y > CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1 > CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 > > With previous kernels, dmesg would show that the sanitizer was indeed > cleaning up the mtrrs [1] > > but now, with 2.6.33-rc7 there is no indication that this is occuring, For those who run across this later, Found out that commit 508d85c2c6bc8cba53d2a54d9a306ad64a0a80bf, x86: When cleaning MTRRs, do not fold WP into UC causes mtrr cleanup not to run on my machine. Probably not worth fixing because the i915 error message is harmless. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: mtrr cleanup not doing anything on 2.6.33-rc7 2010-02-11 1:48 ` Alexander Lam @ 2010-02-11 10:10 ` Carlos R. Mafra 2010-02-11 14:56 ` H. Peter Anvin 0 siblings, 1 reply; 5+ messages in thread From: Carlos R. Mafra @ 2010-02-11 10:10 UTC (permalink / raw) To: Alexander Lam; +Cc: linux-kernel, Yinghai Lu, H. Peter Anvin [Add people in that commit to Cc: list, just in case] On Mi 10.Feb'10 at 20:48:49 -0500, Alexander Lam wrote: > On Wed, Feb 10, 2010 at 3:02 PM, Alexander Lam <lambchop468@gmail.com> wrote: > > > > My kernel config has the following: > > CONFIG_MTRR=y > > CONFIG_MTRR_SANITIZER=y > > CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1 > > CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 > > > > With previous kernels, dmesg would show that the sanitizer was indeed > > cleaning up the mtrrs [1] > > > > but now, with 2.6.33-rc7 there is no indication that this is occuring, > > For those who run across this later, > > Found out that commit 508d85c2c6bc8cba53d2a54d9a306ad64a0a80bf, > x86: When cleaning MTRRs, do not fold WP into UC > > causes mtrr cleanup not to run on my machine. > > Probably not worth fixing because the i915 error message is harmless. > -- > To unsubscribe from this list: send the line "unsubscribe linux-kernel" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > Please read the FAQ at http://www.tux.org/lkml/ ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: mtrr cleanup not doing anything on 2.6.33-rc7 2010-02-11 10:10 ` Carlos R. Mafra @ 2010-02-11 14:56 ` H. Peter Anvin 2010-02-11 17:15 ` Carlos R. Mafra 0 siblings, 1 reply; 5+ messages in thread From: H. Peter Anvin @ 2010-02-11 14:56 UTC (permalink / raw) To: Carlos R. Mafra; +Cc: Alexander Lam, linux-kernel, Yinghai Lu On 02/11/2010 02:10 AM, Carlos R. Mafra wrote: > [Add people in that commit to Cc: list, just in case] > > On Mi 10.Feb'10 at 20:48:49 -0500, Alexander Lam wrote: >> On Wed, Feb 10, 2010 at 3:02 PM, Alexander Lam <lambchop468@gmail.com> wrote: >>> >>> My kernel config has the following: >>> CONFIG_MTRR=y >>> CONFIG_MTRR_SANITIZER=y >>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1 >>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 >>> >>> With previous kernels, dmesg would show that the sanitizer was indeed >>> cleaning up the mtrrs [1] >>> >>> but now, with 2.6.33-rc7 there is no indication that this is occuring, >> >> For those who run across this later, >> >> Found out that commit 508d85c2c6bc8cba53d2a54d9a306ad64a0a80bf, >> x86: When cleaning MTRRs, do not fold WP into UC >> >> causes mtrr cleanup not to run on my machine. >> >> Probably not worth fixing because the i915 error message is harmless. >> -- You're not stating what your MTRR setup looks like, and hence if there is anything to clean up. -hpa -- H. Peter Anvin, Intel Open Source Technology Center I work for Intel. I don't speak on their behalf. ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: mtrr cleanup not doing anything on 2.6.33-rc7 2010-02-11 14:56 ` H. Peter Anvin @ 2010-02-11 17:15 ` Carlos R. Mafra 0 siblings, 0 replies; 5+ messages in thread From: Carlos R. Mafra @ 2010-02-11 17:15 UTC (permalink / raw) To: H. Peter Anvin; +Cc: Alexander Lam, linux-kernel, Yinghai Lu On Do 11.Feb'10 at 6:56:59 -0800, H. Peter Anvin wrote: > On 02/11/2010 02:10 AM, Carlos R. Mafra wrote: > > [Add people in that commit to Cc: list, just in case] > > > > On Mi 10.Feb'10 at 20:48:49 -0500, Alexander Lam wrote: > >> On Wed, Feb 10, 2010 at 3:02 PM, Alexander Lam <lambchop468@gmail.com> wrote: > >>> > >>> My kernel config has the following: > >>> CONFIG_MTRR=y > >>> CONFIG_MTRR_SANITIZER=y > >>> CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1 > >>> CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 > >>> > >>> With previous kernels, dmesg would show that the sanitizer was indeed > >>> cleaning up the mtrrs [1] > >>> > >>> but now, with 2.6.33-rc7 there is no indication that this is occuring, > >> > >> For those who run across this later, > >> > >> Found out that commit 508d85c2c6bc8cba53d2a54d9a306ad64a0a80bf, > >> x86: When cleaning MTRRs, do not fold WP into UC > >> > >> causes mtrr cleanup not to run on my machine. > >> > >> Probably not worth fixing because the i915 error message is harmless. > >> -- > > You're not stating what your MTRR setup looks like, and hence if there > is anything to clean up. I am not sure if I am being an intruder here, but I also should have quoted Alexander's first email: Hi all, Please CC: me when replying. My kernel config has the following: CONFIG_MTRR=y CONFIG_MTRR_SANITIZER=y CONFIG_MTRR_SANITIZER_ENABLE_DEFAULT=1 CONFIG_MTRR_SANITIZER_SPARE_REG_NR_DEFAULT=1 With previous kernels, dmesg would show that the sanitizer was indeed cleaning up the mtrrs [1] but now, with 2.6.33-rc7 there is no indication that this is occuring, and the intel i915 driver complains: [ 0.613419] i915 0000:00:02.0: PCI INT A -> GSI 16 (level, low) -> IRQ 16 [ 0.614577] i915 0000:00:02.0: setting latency timer to 64 [ 0.625446] mtrr: no more MTRRs available [ 0.625529] [drm] MTRR allocation failed. Graphics performance may suffer. What has changed and what do I need to do to make the mtrr sanitation work again? [1]: dmesg from previous kernels: [ 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-C7FFF write-protect [ 0.000000] C8000-EFFFF uncachable [ 0.000000] F0000-FFFFF write-protect [ 0.000000] MTRR variable ranges enabled: [ 0.000000] 0 base 0FFFE0000 mask 0FFFE0000 write-protect [ 0.000000] 1 base 0FFFC0000 mask 0FFFE0000 uncachable [ 0.000000] 2 base 000000000 mask 0E0000000 write-back [ 0.000000] 3 base 020000000 mask 0E0000000 write-back [ 0.000000] 4 base 03F800000 mask 0FF800000 uncachable [ 0.000000] 5 base 03F600000 mask 0FFE00000 uncachable [ 0.000000] 6 base 03F500000 mask 0FFF00000 uncachable [ 0.000000] 7 base 000000000 mask 0FFFE0000 uncachable [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 [ 0.000000] original variable MTRRs [ 0.000000] reg 0, base: 4194176KB, range: 128KB, type WP [ 0.000000] reg 1, base: 4194048KB, range: 128KB, type UC [ 0.000000] reg 2, base: 0GB, range: 512MB, type WB [ 0.000000] reg 3, base: 512MB, range: 512MB, type WB [ 0.000000] reg 4, base: 1016MB, range: 8MB, type UC [ 0.000000] reg 5, base: 1014MB, range: 2MB, type UC [ 0.000000] reg 6, base: 1013MB, range: 1MB, type UC [ 0.000000] reg 7, base: 0GB, range: 128KB, type UC [ 0.000000] WARNING: BIOS bug: VAR MTRR 7 contains strange UC entry under 1M, check with your system vendor! [ 0.000000] total RAM coverred: 1013M [ 0.000000] Found optimal setting for mtrr clean up [ 0.000000] gran_size: 64K chunk_size: 16M num_reg: 4 lose cover RAM: 0G [ 0.000000] New variable MTRRs [ 0.000000] reg 0, base: 0GB, range: 1GB, type WB [ 0.000000] reg 1, base: 1013MB, range: 1MB, type UC [ 0.000000] reg 2, base: 1014MB, range: 2MB, type UC [ 0.000000] reg 3, base: 1016MB, range: 8MB, type UC [ 0.000000] x86 PAT enabled: cpu 0, old 0x7040600070406, new 0x7010600070106 Thanks, -- Alexander Lam ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2010-02-11 17:14 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2010-02-10 20:02 mtrr cleanup not doing anything on 2.6.33-rc7 Alexander Lam 2010-02-11 1:48 ` Alexander Lam 2010-02-11 10:10 ` Carlos R. Mafra 2010-02-11 14:56 ` H. Peter Anvin 2010-02-11 17:15 ` Carlos R. Mafra
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.