From: Yinghai Lu <yinghai@kernel.org>
To: Arjan van de Ven <arjan@linux.intel.com>
Cc: Ingo Molnar <mingo@elte.hu>,
Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Linus Torvalds <torvalds@linux-foundation.org>,
NetDev <netdev@vger.kernel.org>,
x86@kernel.org, Andrew Morton <akpm@linux-foundation.org>,
"Theodore Ts'o" <tytso@mit.edu>,
Alan Cox <alan@lxorguk.ukuu.org.uk>,
jesse Barnes <jbarnes@virtuousgeek.org>
Subject: Re: oops/warning report for the week of November 26, 2008
Date: Thu, 27 Nov 2008 13:18:56 -0800 [thread overview]
Message-ID: <492F0EC0.5030802@kernel.org> (raw)
In-Reply-To: <20081127122800.45fc0b1a@linux.intel.com>
Arjan van de Ven wrote:
> On Thu, 27 Nov 2008 21:18:36 +0100
> Ingo Molnar <mingo@elte.hu> wrote:
>
>> * Arjan van de Ven <arjan@linux.intel.com> wrote:
>>
>>> Ingo Molnar wrote:
>>>> * Arjan van de Ven <arjan@linux.intel.com> wrote:
>>>>
>>>>> Rank 8: mtrr_trim_uncached_memory (warning)
>>>>> Reported 227 times (619 total reports)
>>>>> There is a high number of machines where our MTRR checks
>>>>> trigger. I suspect we are too picky in accepting the MTRR
>>>>> configuration.
>>>> the warning here means: "the BIOS messed up but we fixed it up for
>>>> you just fine".
>>> I don't believe that right now. we see so many of these, including
>>> many "there's no MTRRs at all", that I am seriously suspecting that
>>> our code is just incorrect somehow and triggering too much.
>> well we looked at existing reports and Linux was right to fix them
>> up. Show us one that is incorrect, then we can fix it up.
>>
>> the "no MTRR's" are vmware/(also qemu?) guests not implementing a
>> full CPU emulation.
>
> ... and it's still our fault in part, since we don't even check to see
> if a cpu claims to support MTRR before complaining about it...
>
> easy to fix though:
>
> From 7e987ae541c41ce908b414fee9d8e2fd2099a083 Mon Sep 17 00:00:00 2001
> From: Arjan van de Ven <arjan@linux.intel.com>
> Date: Thu, 27 Nov 2008 12:25:47 -0800
> Subject: [PATCH] x86: make sure the CPU advertizes MTRR support before complaining about the lack thereoff...
>
> We complain loudly if a CPU does not have MTRR support... but we don't check if the CPU
> exposes MTRR support in the CPUID flags first. While this might not fix all of the
> broken virtualization systems out there, it will at least fix those that properly don't
> advertize things they don't support.
>
> Signed-off-by: Arjan van de Ven <arjan@linux.intel.com>
> ---
> arch/x86/kernel/cpu/mtrr/main.c | 2 ++
> 1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/arch/x86/kernel/cpu/mtrr/main.c b/arch/x86/kernel/cpu/mtrr/main.c
> index 1159e26..0044e61 100644
> --- a/arch/x86/kernel/cpu/mtrr/main.c
> +++ b/arch/x86/kernel/cpu/mtrr/main.c
> @@ -1567,6 +1567,8 @@ int __init mtrr_trim_uncached_memory(unsigned long end_pfn)
> * Make sure we only trim uncachable memory on machines that
> * support the Intel MTRR architecture:
> */
> + if (!cpu_has_mtrr)
> + return 0;
that is not needed, we already check that in mtrr_bp_init before this function is called, and it will assign mtrr_if
and
#define is_cpu(vnd) (mtrr_if && mtrr_if->vendor == X86_VENDOR_##vnd)
will make it sure mtrr is there.
ps: here INTEL mean any cpu has same interface like intel cpu's
YH
> if (!is_cpu(INTEL) || disable_mtrr_trim)
> return 0;
> rdmsr(MTRRdefType_MSR, def, dummy);
next prev parent reply other threads:[~2008-11-27 21:20 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-11-26 23:11 oops/warning report for the week of November 26, 2008 Arjan van de Ven
2008-11-27 0:05 ` Jesse Barnes
2008-11-27 11:48 ` Ingo Molnar
2008-11-27 19:42 ` Alex Chiang
2008-11-27 19:49 ` Arjan van de Ven
2008-11-27 11:52 ` Ingo Molnar
2008-11-27 17:02 ` Jesse Barnes
2008-11-27 18:01 ` Arjan van de Ven
2008-11-27 20:18 ` Ingo Molnar
2008-11-27 20:28 ` Arjan van de Ven
2008-11-27 20:47 ` Ingo Molnar
2008-11-27 20:53 ` Arjan van de Ven
2008-11-28 8:34 ` Ingo Molnar
2008-11-27 21:18 ` H. Peter Anvin
2008-11-27 21:18 ` Yinghai Lu [this message]
2008-11-27 21:42 ` H. Peter Anvin
2008-11-28 17:18 ` Jay Cliburn
2008-11-28 17:32 ` Arjan van de Ven
2008-11-28 18:36 ` Jay Cliburn
2008-11-28 18:50 ` Arjan van de Ven
2008-11-28 21:12 ` atl1 transmit timeout Was: " Jay Cliburn
2008-11-28 21:22 ` Arjan van de Ven
2008-11-28 19:50 ` Francois Romieu
2008-11-28 20:12 ` Arjan van de Ven
2008-11-30 8:58 ` Roger Luethi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=492F0EC0.5030802@kernel.org \
--to=yinghai@kernel.org \
--cc=akpm@linux-foundation.org \
--cc=alan@lxorguk.ukuu.org.uk \
--cc=arjan@linux.intel.com \
--cc=jbarnes@virtuousgeek.org \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@elte.hu \
--cc=netdev@vger.kernel.org \
--cc=torvalds@linux-foundation.org \
--cc=tytso@mit.edu \
--cc=x86@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
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.