Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem: BIOS bug: CPU MTRRs don't cover all of memory, Version-Release number of selected component (if applicable): 2.6.25-8.fc9.x86_64 How reproducible: Always Steps to Reproduce: 1.Boot 2. 3. Actual results: Expected results: Additional info: Same system as for https://bugzilla.redhat.com/show_bug.cgi?id=436099 ------------[ cut here ]------------ WARNING: at arch/x86/kernel/cpu/mtrr/main.c:706 mtrr_trim_uncached_memory+0x132/0x19a() (Not tainted) Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.25-8.fc9.x86_64 #1 Call Trace: [<ffffffff81034585>] warn_on_slowpath+0x60/0x91 [<ffffffff81463bee>] ? do_early_param+0x40/0x89 [<ffffffff8146c496>] mtrr_trim_uncached_memory+0x132/0x19a [<ffffffff81469db0>] setup_arch+0x239/0x4ee [<ffffffff8104eb0f>] ? clockevents_register_notifier+0x27/0x34 [<ffffffff81463930>] start_kernel+0x76/0x2f4 [<ffffffff814631d7>] _sinittext+0x1d7/0x1de ---[ end trace ca143223eefdc828 ]---
Your computer has a buggy BIOS. But we shouldn't be dumping a stack trace because of that.
I think I got the same bug booting into the Fedora 9 Preview Live disk: Linux localhost.localdomain 2.6.25-0.234.rc9.git1.fc9.x86_64 #1 SMP Tue Apr 15 18:02:48 EDT 2008 x86_64 x86_64 x86+64 GNU/Linux WARNING: strange, CPU MTRRs all blank? ------------[ cut here ]------------ WARNING: at arch/x86/kernel/cpu/mtrr/main.c:696 mtrr_trim_uncached_memory+0x198/0x19a() (Not tainted) Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.25-0.234.rc9.git1.fc9.x86_64 #1 Call Trace: [warn_on_slowpath+96/145] warn_on_slowpath+0x60/0x91 [do_early_param+64/137] ? do_early_param+0x40/0x89 [mtrr_trim_uncached_memory+408/410] mtrr_trim_uncached_memory+0x198/0x19a [setup_arch+569/1262] setup_arch+0x239/0x4ee [clockevents_register_notifier+39/52] ? clockevents_register_notifier+0x27/0x34 [start_kernel+118/756] start_kernel+0x76/0x2f4 [x86_64_start_kernel+471/478] _sinittext+0x1d7/0x1de ---[ end trace ca143223eefdc828 ]---
Changing version to '9' as part of upcoming Fedora 9 GA. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Hayden - your backtrace (and warning message) is different than John's. Let's not confuse the issue by lumping two distinct reports together. I have the same problem you do, and will open a new bug.
I have same bug. It's not fedora and kernel is vanilla 2.6.25.4. My log: Linux version 2.6.25.4 (metal@zaratustra) (gcc version 4.3.0 (GCC) ) #6 Sun May 18 14:42:14 MSD 2008 BIOS-provided physical RAM map: BIOS-e820: 0000000000000000 - 000000000009fc00 (usable) BIOS-e820: 000000000009fc00 - 00000000000a0000 (reserved) BIOS-e820: 00000000000e0000 - 0000000000100000 (reserved) BIOS-e820: 0000000000100000 - 000000007efd0000 (usable) BIOS-e820: 000000007efd0000 - 000000007efdf000 (ACPI data) BIOS-e820: 000000007efdf000 - 000000007f000000 (ACPI NVS) WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 15MB of RAM. ------------[ cut here ]------------ WARNING: at arch/x86/kernel/cpu/mtrr/main.c:706 mtrr_trim_uncached_memory+0xfa/0x1a0() Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.25.4 #6 [<c011c7bf>] warn_on_slowpath+0x5f/0xa0 [<c04f2249>] mtrr_trim_uncached_memory+0xfa/0x1a0 [<c04f2458>] get_mtrr_state+0x96/0x21d [<c020bedf>] strlcpy+0x1f/0x60 [<c04f0254>] setup_arch+0x222/0x41e [<c04ec807>] start_kernel+0x4d/0x2a4 ======================= ---[ end trace ca143223eefdc828 ]--- update e820 for mtrr modified physical RAM map: modified: 0000000000000000 - 000000000009fc00 (usable) modified: 000000000009fc00 - 00000000000a0000 (reserved) modified: 00000000000e0000 - 0000000000100000 (reserved) modified: 0000000000100000 - 000000007e000000 (usable) modified: 000000007e000000 - 000000007efd0000 (reserved) modified: 000000007efd0000 - 000000007efdf000 (ACPI data) modified: 000000007efdf000 - 000000007f000000 (ACPI NVS) 1120MB HIGHMEM available. 896MB LOWMEM available. I have idea why it's happing. Bios reports memory size without stolen memory for video card, kernel compares with full memory size. So, there is difference 16Mb. The my machine is laptop and it has integrated video.
can you paste /proc/mtrr here please ?
bash-3.2$ cat /proc/mtrr reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1 reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1 reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1 reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1 reg04: base=0x78000000 (1920MB), size= 64MB: write-back, count=1 reg05: base=0x7c000000 (1984MB), size= 32MB: write-back, count=1 reg06: base=0xd8000000 (3456MB), size= 128MB: write-combining, count=1
adding up the first 6 MTRRs gets to 2016MB, which means 32MB is missing. There should also be another mtrr entry with size=16MB, but for some reason, the BIOS neglected to create one, so Linux is right to report that the BIOS has a bug here. What's also odd is that something has set up a 128MB MTRR. If your integrated video is stealing 16MB for video ram, I have no idea what could be also setting up a 128MB range.
Last line is work of X. X clips 128Mb. I do init 3. After this: reg00: base=0x00000000 ( 0MB), size=1024MB: write-back, count=1 reg01: base=0x40000000 (1024MB), size= 512MB: write-back, count=1 reg02: base=0x60000000 (1536MB), size= 256MB: write-back, count=1 reg03: base=0x70000000 (1792MB), size= 128MB: write-back, count=1 reg04: base=0x78000000 (1920MB), size= 64MB: write-back, count=1 reg05: base=0x7c000000 (1984MB), size= 32MB: write-back, count=1
The real problem is, we are throwing dire error messages when the code is doing what is supposed to do by trimming the memory. The message should be at KERN_INFO level and no stacktrace should be printed.
Created attachment 308736 [details] boot.log
Still there with 2.6.25.4-30.fc9.i686, but perhaps more exotic: x86_32 FC9 in an vmware under winXP (x86_32, AMD64 X2): WARNING: strange, CPU MTRRs all blank? ------------[ cut here ]------------ WARNING: at arch/x86/kernel/cpu/mtrr/main.c:696 mtrr_trim_uncached_memory+0x190/0x195() (Not tainted) Modules linked in: Pid: 0, comm: swapper Not tainted 2.6.25.4-30.fc9.i686 #1 [<c0426bad>] warn_on_slowpath+0x47/0x73 [<c04f3fb4>] ? vsnprintf+0x3e7/0x420 [<c062ae61>] ? _spin_unlock_irqrestore+0x10/0x14 [<c0427071>] ? release_console_sem+0x195/0x19d [<c0427558>] ? vprintk+0x301/0x330 [<c076d331>] ? setup_early_serial8250_console+0x25/0x3b5 [<c0427558>] ? vprintk+0x301/0x330 [<c074e95e>] ? do_early_param+0x40/0x6f [<c0756e26>] mtrr_trim_uncached_memory+0x190/0x195 [<c0754d5b>] setup_arch+0x27b/0x449 [<c074e63f>] start_kernel+0x66/0x345 ======================= ---[ end trace ca143223eefdc828 ]--- /proc/mtrr is empty. System is fine though.
Here is mine from booting the F10 Preview release in qemu-kvm from F8, /proc/mtrr is also empty. <4>------------[ cut here ]------------ <4>WARNING: at arch/x86/kernel/cpu/mtrr/main.c:1500 mtrr_trim_uncached_memory+0x30a/0x311() <4>WARNING: strange, CPU MTRRs all blank? <4>Modules linked in: <4>Pid: 0, comm: swapper Not tainted 2.6.27.4-68.fc10.i586 #1 <4> [<c042b97a>] warn_slowpath+0x4b/0x6c <4> [<c06c5854>] ? _spin_unlock_irqrestore+0x1b/0x38 <4> [<c06c3a00>] ? printk+0xf/0x17 <4> [<c040e0d8>] ? mtrr_wrmsr+0x12/0x35 <4> [<c083f453>] ? get_mtrr_state+0x298/0x2ba <4> [<c083f45a>] ? get_mtrr_state+0x29f/0x2ba <4> [<c083f0de>] mtrr_trim_uncached_memory+0x30a/0x311 <4> [<c06c3a00>] ? printk+0xf/0x17 <4> [<c083bcee>] ? e820_end_pfn+0xa2/0xac <4> [<c083a658>] setup_arch+0x47b/0x957 <4> [<c042c560>] ? vprintk+0x2ce/0x2f3 <4> [<c083c840>] ? __reserve_early+0xf7/0x10b <4> [<c06c3a00>] ? printk+0xf/0x17 <4> [<c0834601>] start_kernel+0x73/0x2f0 <4> [<c0834080>] __init_begin+0x80/0x88 <4> ======================= <4>---[ end trace 4eaa2a86a8e2da22 ]---
For the VWMare and qemu cases, see bug 447097. From that bug, this message is supposed to be suppressed and for some reason is not. The error message looks dire, but is in fact harmless.
This message is a reminder that Fedora 9 is nearing its end of life. Approximately 30 (thirty) days from now Fedora will stop maintaining and issuing updates for Fedora 9. 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 '9'. 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 9'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 9 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
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.