Bug 11490 - Old mtrr bug comeback
Summary: Old mtrr bug comeback
Status: CLOSED OBSOLETE
Alias: None
Product: Memory Management
Classification: Unclassified
Component: MTTR (show other bugs)
Hardware: All Linux
: P1 normal
Assignee: Andrew Morton
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2008-09-03 08:44 UTC by Alexey Kuznetsov
Modified: 2012-05-22 13:46 UTC (History)
3 users (show)

See Also:
Kernel Version: 2.6.27-rc5
Tree: Mainline
Regression: No


Attachments
dmesg (22.96 KB, text/plain)
2008-09-03 08:45 UTC, Alexey Kuznetsov
Details
dmesg with debug flags (67.11 KB, text/plain)
2008-09-04 02:24 UTC, Alexey Kuznetsov
Details
mtrr (538 bytes, text/plain)
2008-09-04 02:25 UTC, Alexey Kuznetsov
Details

Description Alexey Kuznetsov 2008-09-03 08:44:26 UTC
Latest working kernel version:v2.6.26.3

Old mtrr bug comeback, when i boot my notebook with last kerenl they going to work really slow as turttle. to boot on normal speed i need use kernel param mem=1000M

when i use 2.6.26.3 everyting going fine. as i remember that bug fixed in 2.6.26 stable release and was in 2.6.25 and earlier.

probably you can find more details in bugzilla.redhat.com or bugzilla.mozilla.com i do no remember where is exactly i have been posted that old bug.

here the point (warning on 2.6.26.3 kernel):

WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 7MB of RAM.
------------[ cut here ]------------
WARNING: at arch/x86/kernel/cpu/mtrr/main.c:706 mtrr_trim_uncached_memory+0x103/0x168()
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.26.3 #1
 [<c06260e9>] ? printk+0xf/0x16
 [<c0427749>] warn_on_slowpath+0x41/0x7b
 [<c0628171>] ? _spin_unlock_irqrestore+0x10/0x14
 [<c0628171>] ? _spin_unlock_irqrestore+0x10/0x14
 [<c0427e4f>] ? release_console_sem+0x181/0x189
 [<c04282d3>] ? vprintk+0x2e6/0x30b
 [<c04282d3>] ? vprintk+0x2e6/0x30b
 [<c040dbfd>] ? generic_get_mtrr+0x53/0x8a
 [<c0756177>] mtrr_trim_uncached_memory+0x103/0x168
 [<c075606c>] ? mtrr_bp_init+0x204/0x20c
 [<c07539a9>] setup_arch+0x27b/0x6ce
 [<c06260e9>] ? printk+0xf/0x16
 [<c074d5c0>] start_kernel+0x64/0x2da
 [<c074d008>] __init_begin+0x8/0xa
 =======================
---[ end trace 4eaa2a86a8e2da22 ]---
update e820 for mtrr
modified physical RAM map:
Comment 1 Alexey Kuznetsov 2008-09-03 08:45:34 UTC
Created attachment 17597 [details]
dmesg

full log of 2.6.26.3
Comment 2 Anonymous Emailer 2008-09-03 09:19:13 UTC
Reply-To: akpm@linux-foundation.org


(switched to email.  Please respond via emailed reply-to-all, not via the
bugzilla web interface).

On Wed,  3 Sep 2008 08:44:27 -0700 (PDT) bugme-daemon@bugzilla.kernel.org wrote:

> http://bugzilla.kernel.org/show_bug.cgi?id=11490
> 
>            Summary: Old mtrr bug comeback
>            Product: Memory Management
>            Version: 2.5
>      KernelVersion: v2.6.27-rc5
>           Platform: All
>         OS/Version: Linux
>               Tree: Mainline
>             Status: NEW
>           Severity: normal
>           Priority: P1
>          Component: MTTR
>         AssignedTo: akpm@osdl.org
>         ReportedBy: ak@axet.ru
> 
> 
> Latest working kernel version:v2.6.26.3
> 
> Old mtrr bug comeback, when i boot my notebook with last kerenl they going to
> work really slow as turttle. to boot on normal speed i need use kernel param
> mem=1000M
> 
> when i use 2.6.26.3 everyting going fine. as i remember that bug fixed in
> 2.6.26 stable release and was in 2.6.25 and earlier.
> 
> probably you can find more details in bugzilla.redhat.com or
> bugzilla.mozilla.com i do no remember where is exactly i have been posted
> that
> old bug.
> 
> here the point (warning on 2.6.26.3 kernel):
> 
> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 7MB of RAM.
> ------------[ cut here ]------------
> WARNING: at arch/x86/kernel/cpu/mtrr/main.c:706
> mtrr_trim_uncached_memory+0x103/0x168()
> Modules linked in:
> Pid: 0, comm: swapper Not tainted 2.6.26.3 #1
>  [<c06260e9>] ? printk+0xf/0x16
>  [<c0427749>] warn_on_slowpath+0x41/0x7b
>  [<c0628171>] ? _spin_unlock_irqrestore+0x10/0x14
>  [<c0628171>] ? _spin_unlock_irqrestore+0x10/0x14
>  [<c0427e4f>] ? release_console_sem+0x181/0x189
>  [<c04282d3>] ? vprintk+0x2e6/0x30b
>  [<c04282d3>] ? vprintk+0x2e6/0x30b
>  [<c040dbfd>] ? generic_get_mtrr+0x53/0x8a
>  [<c0756177>] mtrr_trim_uncached_memory+0x103/0x168
>  [<c075606c>] ? mtrr_bp_init+0x204/0x20c
>  [<c07539a9>] setup_arch+0x27b/0x6ce
>  [<c06260e9>] ? printk+0xf/0x16
>  [<c074d5c0>] start_kernel+0x64/0x2da
>  [<c074d008>] __init_begin+0x8/0xa
>  =======================
> ---[ end trace 4eaa2a86a8e2da22 ]---
> update e820 for mtrr
> modified physical RAM map:
> 

A post-2.6.26 regression.

We have a couple of mtrr fixes pending:

http://userweb.kernel.org/~akpm/mmotm/broken-out/x86-delay-early-cpu-initialization-until-cpuid-is-done.patch

http://userweb.kernel.org/~akpm/mmotm/broken-out/x86-move-mtrr-cpu-cap-setting-early-in-early_init_xxxx.patch

but I don't know if they'll fix this regression?
Comment 3 Alexey Kuznetsov 2008-09-03 09:52:26 UTC
old reported bug:

http://bugzilla.kernel.org/show_bug.cgi?id=10034
Comment 4 Yinghai Lu 2008-09-03 09:55:20 UTC
On Wed, Sep 3, 2008 at 9:18 AM, Andrew Morton <akpm@linux-foundation.org> wrote:
>
> (switched to email.  Please respond via emailed reply-to-all, not via the
> bugzilla web interface).
>
> On Wed,  3 Sep 2008 08:44:27 -0700 (PDT) bugme-daemon@bugzilla.kernel.org
> wrote:
>
>> http://bugzilla.kernel.org/show_bug.cgi?id=11490
>>
>>            Summary: Old mtrr bug comeback
>>            Product: Memory Management
>>            Version: 2.5
>>      KernelVersion: v2.6.27-rc5
>>           Platform: All
>>         OS/Version: Linux
>>               Tree: Mainline
>>             Status: NEW
>>           Severity: normal
>>           Priority: P1
>>          Component: MTTR
>>         AssignedTo: akpm@osdl.org
>>         ReportedBy: ak@axet.ru
>>
>>
>> Latest working kernel version:v2.6.26.3
>>
>> Old mtrr bug comeback, when i boot my notebook with last kerenl they going
>> to
>> work really slow as turttle. to boot on normal speed i need use kernel param
>> mem=1000M
>>
>> when i use 2.6.26.3 everyting going fine. as i remember that bug fixed in
>> 2.6.26 stable release and was in 2.6.25 and earlier.
>>
>> probably you can find more details in bugzilla.redhat.com or
>> bugzilla.mozilla.com i do no remember where is exactly i have been posted
>> that
>> old bug.
>>
>> here the point (warning on 2.6.26.3 kernel):
>>
>> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 7MB of RAM.
>> ------------[ cut here ]------------
>> WARNING: at arch/x86/kernel/cpu/mtrr/main.c:706
>> mtrr_trim_uncached_memory+0x103/0x168()
>> Modules linked in:
>> Pid: 0, comm: swapper Not tainted 2.6.26.3 #1
>>  [<c06260e9>] ? printk+0xf/0x16
>>  [<c0427749>] warn_on_slowpath+0x41/0x7b
>>  [<c0628171>] ? _spin_unlock_irqrestore+0x10/0x14
>>  [<c0628171>] ? _spin_unlock_irqrestore+0x10/0x14
>>  [<c0427e4f>] ? release_console_sem+0x181/0x189
>>  [<c04282d3>] ? vprintk+0x2e6/0x30b
>>  [<c04282d3>] ? vprintk+0x2e6/0x30b
>>  [<c040dbfd>] ? generic_get_mtrr+0x53/0x8a
>>  [<c0756177>] mtrr_trim_uncached_memory+0x103/0x168
>>  [<c075606c>] ? mtrr_bp_init+0x204/0x20c
>>  [<c07539a9>] setup_arch+0x27b/0x6ce
>>  [<c06260e9>] ? printk+0xf/0x16
>>  [<c074d5c0>] start_kernel+0x64/0x2da
>>  [<c074d008>] __init_begin+0x8/0xa
>>  =======================
>> ---[ end trace 4eaa2a86a8e2da22 ]---
>> update e820 for mtrr
>> modified physical RAM map:
>>
>
> A post-2.6.26 regression.
>
> We have a couple of mtrr fixes pending:
>
>
> http://userweb.kernel.org/~akpm/mmotm/broken-out/x86-delay-early-cpu-initialization-until-cpuid-is-done.patch
>
>
> http://userweb.kernel.org/~akpm/mmotm/broken-out/x86-move-mtrr-cpu-cap-setting-early-in-early_init_xxxx.patch
>
> but I don't know if they'll fix this regression?
>

cpu?

dmesg  with debug and initcall_debug

cat /proc/mtrr

YH
Comment 5 Alexey Kuznetsov 2008-09-03 10:09:21 UTC
Can you explain what mean debug and initcall_debug?

2008/9/3 Yinghai Lu <yhlu.kernel@gmail.com>

> On Wed, Sep 3, 2008 at 9:18 AM, Andrew Morton <akpm@linux-foundation.org>
> wrote:
> >
> > (switched to email.  Please respond via emailed reply-to-all, not via the
> > bugzilla web interface).
> >
> > On Wed,  3 Sep 2008 08:44:27 -0700 (PDT)
> bugme-daemon@bugzilla.kernel.org wrote:
> >
> >> http://bugzilla.kernel.org/show_bug.cgi?id=11490
> >>
> >>            Summary: Old mtrr bug comeback
> >>            Product: Memory Management
> >>            Version: 2.5
> >>      KernelVersion: v2.6.27-rc5
> >>           Platform: All
> >>         OS/Version: Linux
> >>               Tree: Mainline
> >>             Status: NEW
> >>           Severity: normal
> >>           Priority: P1
> >>          Component: MTTR
> >>         AssignedTo: akpm@osdl.org
> >>         ReportedBy: ak@axet.ru
> >>
> >>
> >> Latest working kernel version:v2.6.26.3
> >>
> >> Old mtrr bug comeback, when i boot my notebook with last kerenl they
> going to
> >> work really slow as turttle. to boot on normal speed i need use kernel
> param
> >> mem=1000M
> >>
> >> when i use 2.6.26.3 everyting going fine. as i remember that bug fixed
> in
> >> 2.6.26 stable release and was in 2.6.25 and earlier.
> >>
> >> probably you can find more details in bugzilla.redhat.com or
> >> bugzilla.mozilla.com i do no remember where is exactly i have been
> posted that
> >> old bug.
> >>
> >> here the point (warning on 2.6.26.3 kernel):
> >>
> >> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 7MB of
> RAM.
> >> ------------[ cut here ]------------
> >> WARNING: at arch/x86/kernel/cpu/mtrr/main.c:706
> >> mtrr_trim_uncached_memory+0x103/0x168()
> >> Modules linked in:
> >> Pid: 0, comm: swapper Not tainted 2.6.26.3 #1
> >>  [<c06260e9>] ? printk+0xf/0x16
> >>  [<c0427749>] warn_on_slowpath+0x41/0x7b
> >>  [<c0628171>] ? _spin_unlock_irqrestore+0x10/0x14
> >>  [<c0628171>] ? _spin_unlock_irqrestore+0x10/0x14
> >>  [<c0427e4f>] ? release_console_sem+0x181/0x189
> >>  [<c04282d3>] ? vprintk+0x2e6/0x30b
> >>  [<c04282d3>] ? vprintk+0x2e6/0x30b
> >>  [<c040dbfd>] ? generic_get_mtrr+0x53/0x8a
> >>  [<c0756177>] mtrr_trim_uncached_memory+0x103/0x168
> >>  [<c075606c>] ? mtrr_bp_init+0x204/0x20c
> >>  [<c07539a9>] setup_arch+0x27b/0x6ce
> >>  [<c06260e9>] ? printk+0xf/0x16
> >>  [<c074d5c0>] start_kernel+0x64/0x2da
> >>  [<c074d008>] __init_begin+0x8/0xa
> >>  =======================
> >> ---[ end trace 4eaa2a86a8e2da22 ]---
> >> update e820 for mtrr
> >> modified physical RAM map:
> >>
> >
> > A post-2.6.26 regression.
> >
> > We have a couple of mtrr fixes pending:
> >
> >
>
> http://userweb.kernel.org/~akpm/mmotm/broken-out/x86-delay-early-cpu-initialization-until-cpuid-is-done.patch<http://userweb.kernel.org/%7Eakpm/mmotm/broken-out/x86-delay-early-cpu-initialization-until-cpuid-is-done.patch>
> >
> >
>
> http://userweb.kernel.org/~akpm/mmotm/broken-out/x86-move-mtrr-cpu-cap-setting-early-in-early_init_xxxx.patch<http://userweb.kernel.org/%7Eakpm/mmotm/broken-out/x86-move-mtrr-cpu-cap-setting-early-in-early_init_xxxx.patch>
> >
> > but I don't know if they'll fix this regression?
> >
>
> cpu?
>
> dmesg  with debug and initcall_debug
>
> cat /proc/mtrr
>
> YH
>
<div dir="ltr">Can you explain what mean debug and initcall_debug?<br><br><div class="gmail_quote">2008/9/3 Yinghai Lu <span dir="ltr">&lt;<a href="mailto:yhlu.kernel@gmail.com">yhlu.kernel@gmail.com</a>&gt;</span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div><div></div><div class="Wj3C7c">On Wed, Sep 3, 2008 at 9:18 AM, Andrew Morton &lt;<a href="mailto:akpm@linux-foundation.org">akpm@linux-foundation.org</a>&gt; wrote:<br>
&gt;<br>
&gt; (switched to email. &nbsp;Please respond via emailed reply-to-all, not via the<br>
&gt; bugzilla web interface).<br>
&gt;<br>
&gt; On Wed, &nbsp;3 Sep 2008 08:44:27 -0700 (PDT) <a href="mailto:bugme-daemon@bugzilla.kernel.org">bugme-daemon@bugzilla.kernel.org</a> wrote:<br>
&gt;<br>
&gt;&gt; <a href="http://bugzilla.kernel.org/show_bug.cgi?id=11490" target="_blank">http://bugzilla.kernel.org/show_bug.cgi?id=11490</a><br>
&gt;&gt;<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Summary: Old mtrr bug comeback<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Product: Memory Management<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Version: 2.5<br>
&gt;&gt; &nbsp; &nbsp; &nbsp;KernelVersion: v2.6.27-rc5<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Platform: All<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; OS/Version: Linux<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Tree: Mainline<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Status: NEW<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Severity: normal<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp; Priority: P1<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; &nbsp;Component: MTTR<br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; AssignedTo: <a href="mailto:akpm@osdl.org">akpm@osdl.org</a><br>
&gt;&gt; &nbsp; &nbsp; &nbsp; &nbsp; ReportedBy: <a href="mailto:ak@axet.ru">ak@axet.ru</a><br>
&gt;&gt;<br>
&gt;&gt;<br>
&gt;&gt; Latest working kernel version:v2.6.26.3<br>
&gt;&gt;<br>
&gt;&gt; Old mtrr bug comeback, when i boot my notebook with last kerenl they going to<br>
&gt;&gt; work really slow as turttle. to boot on normal speed i need use kernel param<br>
&gt;&gt; mem=1000M<br>
&gt;&gt;<br>
&gt;&gt; when i use <a href="http://2.6.26.3" target="_blank">2.6.26.3</a> everyting going fine. as i remember that bug fixed in<br>
&gt;&gt; 2.6.26 stable release and was in 2.6.25 and earlier.<br>
&gt;&gt;<br>
&gt;&gt; probably you can find more details in <a href="http://bugzilla.redhat.com" target="_blank">bugzilla.redhat.com</a> or<br>
&gt;&gt; <a href="http://bugzilla.mozilla.com" target="_blank">bugzilla.mozilla.com</a> i do no remember where is exactly i have been posted that<br>
&gt;&gt; old bug.<br>
&gt;&gt;<br>
&gt;&gt; here the point (warning on <a href="http://2.6.26.3" target="_blank">2.6.26.3</a> kernel):<br>
&gt;&gt;<br>
&gt;&gt; WARNING: BIOS bug: CPU MTRRs don&#39;t cover all of memory, losing 7MB of RAM.<br>
&gt;&gt; ------------[ cut here ]------------<br>
&gt;&gt; WARNING: at arch/x86/kernel/cpu/mtrr/main.c:706<br>
&gt;&gt; mtrr_trim_uncached_memory+0x103/0x168()<br>
&gt;&gt; Modules linked in:<br>
&gt;&gt; Pid: 0, comm: swapper Not tainted <a href="http://2.6.26.3" target="_blank">2.6.26.3</a> #1<br>
&gt;&gt; &nbsp;[&lt;c06260e9&gt;] ? printk+0xf/0x16<br>
&gt;&gt; &nbsp;[&lt;c0427749&gt;] warn_on_slowpath+0x41/0x7b<br>
&gt;&gt; &nbsp;[&lt;c0628171&gt;] ? _spin_unlock_irqrestore+0x10/0x14<br>
&gt;&gt; &nbsp;[&lt;c0628171&gt;] ? _spin_unlock_irqrestore+0x10/0x14<br>
&gt;&gt; &nbsp;[&lt;c0427e4f&gt;] ? release_console_sem+0x181/0x189<br>
&gt;&gt; &nbsp;[&lt;c04282d3&gt;] ? vprintk+0x2e6/0x30b<br>
&gt;&gt; &nbsp;[&lt;c04282d3&gt;] ? vprintk+0x2e6/0x30b<br>
&gt;&gt; &nbsp;[&lt;c040dbfd&gt;] ? generic_get_mtrr+0x53/0x8a<br>
&gt;&gt; &nbsp;[&lt;c0756177&gt;] mtrr_trim_uncached_memory+0x103/0x168<br>
&gt;&gt; &nbsp;[&lt;c075606c&gt;] ? mtrr_bp_init+0x204/0x20c<br>
&gt;&gt; &nbsp;[&lt;c07539a9&gt;] setup_arch+0x27b/0x6ce<br>
&gt;&gt; &nbsp;[&lt;c06260e9&gt;] ? printk+0xf/0x16<br>
&gt;&gt; &nbsp;[&lt;c074d5c0&gt;] start_kernel+0x64/0x2da<br>
&gt;&gt; &nbsp;[&lt;c074d008&gt;] __init_begin+0x8/0xa<br>
&gt;&gt; &nbsp;=======================<br>
&gt;&gt; ---[ end trace 4eaa2a86a8e2da22 ]---<br>
&gt;&gt; update e820 for mtrr<br>
&gt;&gt; modified physical RAM map:<br>
&gt;&gt;<br>
&gt;<br>
&gt; A post-2.6.26 regression.<br>
&gt;<br>
&gt; We have a couple of mtrr fixes pending:<br>
&gt;<br>
&gt; <a href="http://userweb.kernel.org/%7Eakpm/mmotm/broken-out/x86-delay-early-cpu-initialization-until-cpuid-is-done.patch" target="_blank">http://userweb.kernel.org/~akpm/mmotm/broken-out/x86-delay-early-cpu-initialization-until-cpuid-is-done.patch</a><br>

&gt;<br>
&gt; <a href="http://userweb.kernel.org/%7Eakpm/mmotm/broken-out/x86-move-mtrr-cpu-cap-setting-early-in-early_init_xxxx.patch" target="_blank">http://userweb.kernel.org/~akpm/mmotm/broken-out/x86-move-mtrr-cpu-cap-setting-early-in-early_init_xxxx.patch</a><br>

&gt;<br>
&gt; but I don&#39;t know if they&#39;ll fix this regression?<br>
&gt;<br>
<br>
</div></div>cpu?<br>
<br>
dmesg &nbsp;with debug and initcall_debug<br>
<br>
cat /proc/mtrr<br>
<br>
YH<br>
</blockquote></div><br><br clear="all"><br>
</div>
Comment 6 Yinghai Lu 2008-09-03 10:59:26 UTC
On Wed, Sep 3, 2008 at 10:08 AM, Alexey Kuznetsov <ak@axet.ru> wrote:
> Can you explain what mean debug and initcall_debug?

put "debug initcall_debug" in to grub.conf or pxe conf.

YH
Comment 7 Alexey Kuznetsov 2008-09-04 02:24:43 UTC
Created attachment 17614 [details]
dmesg with debug flags
Comment 8 Alexey Kuznetsov 2008-09-04 02:25:12 UTC
Created attachment 17615 [details]
mtrr
Comment 9 Alexey Kuznetsov 2008-09-04 02:26:16 UTC
dmesg with debug and mtrr without mem=1000M param
Comment 10 Alexey Kuznetsov 2008-09-06 09:24:17 UTC
i tried these patches on 2.6.27 - same issue (slow)

> cpu?
Intel(R) Pentium(R) M processor 1600MHz
Comment 11 Alexey Kuznetsov 2008-10-07 03:25:03 UTC
still confirm the bug: 2.6.27-rc9
Comment 12 Joshua Hoblitt 2008-12-02 13:24:29 UTC
I think I've hit this bug on 2.6.28-rc6.  This is on the same system as in bug #11388.  Which was not only fixed by the patch but has since had it's BIOS upgraded to a version which also fixed the MTRR issue.

[    0.000000] ------------[ cut here ]------------
[    0.000000] WARNING: at arch/x86/kernel/cpu/mtrr/generic.c:404 generic_get_mtrr+0xb6/0xef()
[    0.000000] mtrr: your BIOS has set up an incorrect mask, fixing it up.
[    0.000000] Modules linked in:
[    0.000000] Pid: 0, comm: swapper Not tainted 2.6.28-rc6-00209-g6a12141 #3
[    0.000000] Call Trace:
[    0.000000]  [<ffffffff8023976c>] warn_slowpath+0xb4/0xd2
[    0.000000]  [<ffffffff80239d5d>] release_console_sem+0x3e/0x1a5
[    0.000000]  [<ffffffff80239ea9>] release_console_sem+0x18a/0x1a5
[    0.000000]  [<ffffffff8039d039>] sprintf+0x51/0x59
[    0.000000]  [<ffffffff8020e57f>] dump_trace+0x2e0/0x32f
[    0.000000]  [<ffffffff8023a475>] printk+0x4e/0x56
[    0.000000]  [<ffffffff8021a0ff>] generic_get_mtrr+0xb6/0xef
[    0.000000]  [<ffffffff8088d9c5>] mtrr_trim_uncached_memory+0x7b/0x556
[    0.000000]  [<ffffffff805b6ed0>] _spin_unlock+0x17/0x20
[    0.000000]  [<ffffffff8088a211>] setup_arch+0x3b3/0x6e8
[    0.000000]  [<ffffffff8088396c>] start_kernel+0x79/0x36f
[    0.000000]  [<ffffffff8088338f>] x86_64_start_kernel+0xde/0xe2
[    0.000000] ---[ end trace 4eaa2a86a8e2da22 ]---
Comment 13 Joshua Hoblitt 2008-12-02 13:25:50 UTC
I should add that this system is indeed showing the correct amount of memory.
Comment 14 Ed Martin 2008-12-26 22:10:01 UTC
and i have the same thing:

------------[ cut here ]------------
WARNING: at arch/x86/kernel/cpu/mtrr/generic.c:404 generic_get_mtrr+0x11e/0x130()
mtrr: your BIOS has set up an incorrect mask, fixing it up.
Modules linked in:
Pid: 0, comm: swapper Not tainted 2.6.28 #1
Call Trace:
 [<ffffffff802562ad>] warn_slowpath+0xcd/0x110
 [<ffffffff80256b17>] release_console_sem+0x197/0x1e0
 [<ffffffff802575be>] printk+0x4e/0x60
 [<ffffffff80d8ad3e>] dmi_string_nosave+0x5e/0x90
 [<ffffffff802371ce>] generic_get_mtrr+0x11e/0x130
 [<ffffffff80d63a3d>] mtrr_bp_init+0x1cd/0xb10
 [<ffffffff80d6c788>] early_gart_iommu_check+0xb8/0x2d0
 [<ffffffff80d5ed0e>] setup_arch+0x42e/0x8d0
 [<ffffffff80d578bc>] start_kernel+0x5c/0x3b0
 [<ffffffff80d573aa>] x86_64_start_kernel+0xca/0xe0
---[ end trace 4eaa2a86a8e2da22 ]---

all the MTRR stuff seems to be working and i can see all of my 8GB of RAM, and this is on a system that had problems with the MTRR and requires the MTRR fixup stuff

this is 2.6.28

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