Bug 11490
| Summary: | Old mtrr bug comeback | ||
|---|---|---|---|
| Product: | Memory Management | Reporter: | Alexey Kuznetsov (axet) |
| Component: | MTTR | Assignee: | Andrew Morton (akpm) |
| Status: | CLOSED OBSOLETE | ||
| Severity: | normal | CC: | alan, edman007, j_kernel |
| Priority: | P1 | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Kernel Version: | 2.6.27-rc5 | Subsystem: | |
| Regression: | No | Bisected commit-id: | |
| Attachments: |
dmesg
dmesg with debug flags mtrr |
||
|
Description
Alexey Kuznetsov
2008-09-03 08:44:26 UTC
Created attachment 17597 [details]
dmesg
full log of 2.6.26.3
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? old reported bug: http://bugzilla.kernel.org/show_bug.cgi?id=10034 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 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"><<a href="mailto:yhlu.kernel@gmail.com">yhlu.kernel@gmail.com</a>></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 <<a href="mailto:akpm@linux-foundation.org">akpm@linux-foundation.org</a>> wrote:<br> ><br> > (switched to email. Please respond via emailed reply-to-all, not via the<br> > bugzilla web interface).<br> ><br> > On Wed, 3 Sep 2008 08:44:27 -0700 (PDT) <a href="mailto:bugme-daemon@bugzilla.kernel.org">bugme-daemon@bugzilla.kernel.org</a> wrote:<br> ><br> >> <a href="http://bugzilla.kernel.org/show_bug.cgi?id=11490" target="_blank">http://bugzilla.kernel.org/show_bug.cgi?id=11490</a><br> >><br> >> Summary: Old mtrr bug comeback<br> >> Product: Memory Management<br> >> Version: 2.5<br> >> KernelVersion: v2.6.27-rc5<br> >> Platform: All<br> >> OS/Version: Linux<br> >> Tree: Mainline<br> >> Status: NEW<br> >> Severity: normal<br> >> Priority: P1<br> >> Component: MTTR<br> >> AssignedTo: <a href="mailto:akpm@osdl.org">akpm@osdl.org</a><br> >> ReportedBy: <a href="mailto:ak@axet.ru">ak@axet.ru</a><br> >><br> >><br> >> Latest working kernel version:v2.6.26.3<br> >><br> >> Old mtrr bug comeback, when i boot my notebook with last kerenl they going to<br> >> work really slow as turttle. to boot on normal speed i need use kernel param<br> >> mem=1000M<br> >><br> >> 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> >> 2.6.26 stable release and was in 2.6.25 and earlier.<br> >><br> >> probably you can find more details in <a href="http://bugzilla.redhat.com" target="_blank">bugzilla.redhat.com</a> or<br> >> <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> >> old bug.<br> >><br> >> here the point (warning on <a href="http://2.6.26.3" target="_blank">2.6.26.3</a> kernel):<br> >><br> >> WARNING: BIOS bug: CPU MTRRs don't cover all of memory, losing 7MB of RAM.<br> >> ------------[ cut here ]------------<br> >> WARNING: at arch/x86/kernel/cpu/mtrr/main.c:706<br> >> mtrr_trim_uncached_memory+0x103/0x168()<br> >> Modules linked in:<br> >> Pid: 0, comm: swapper Not tainted <a href="http://2.6.26.3" target="_blank">2.6.26.3</a> #1<br> >> [<c06260e9>] ? printk+0xf/0x16<br> >> [<c0427749>] warn_on_slowpath+0x41/0x7b<br> >> [<c0628171>] ? _spin_unlock_irqrestore+0x10/0x14<br> >> [<c0628171>] ? _spin_unlock_irqrestore+0x10/0x14<br> >> [<c0427e4f>] ? release_console_sem+0x181/0x189<br> >> [<c04282d3>] ? vprintk+0x2e6/0x30b<br> >> [<c04282d3>] ? vprintk+0x2e6/0x30b<br> >> [<c040dbfd>] ? generic_get_mtrr+0x53/0x8a<br> >> [<c0756177>] mtrr_trim_uncached_memory+0x103/0x168<br> >> [<c075606c>] ? mtrr_bp_init+0x204/0x20c<br> >> [<c07539a9>] setup_arch+0x27b/0x6ce<br> >> [<c06260e9>] ? printk+0xf/0x16<br> >> [<c074d5c0>] start_kernel+0x64/0x2da<br> >> [<c074d008>] __init_begin+0x8/0xa<br> >> =======================<br> >> ---[ end trace 4eaa2a86a8e2da22 ]---<br> >> update e820 for mtrr<br> >> modified physical RAM map:<br> >><br> ><br> > A post-2.6.26 regression.<br> ><br> > We have a couple of mtrr fixes pending:<br> ><br> > <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> ><br> > <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> ><br> > but I don't know if they'll fix this regression?<br> ><br> <br> </div></div>cpu?<br> <br> dmesg with debug and initcall_debug<br> <br> cat /proc/mtrr<br> <br> YH<br> </blockquote></div><br><br clear="all"><br> </div> 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 Created attachment 17614 [details]
dmesg with debug flags
Created attachment 17615 [details]
mtrr
dmesg with debug and mtrr without mem=1000M param i tried these patches on 2.6.27 - same issue (slow)
> cpu?
Intel(R) Pentium(R) M processor 1600MHz
still confirm the bug: 2.6.27-rc9 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 ]--- I should add that this system is indeed showing the correct amount of memory. 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 |