From: Ingo Molnar <mingo@kernel.org>
To: "H. Peter Anvin" <hpa@linux.intel.com>
Cc: Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
Thomas Gleixner <tglx@linutronix.de>,
Olof Johansson <olof@lixom.net>
Subject: Re: [RFC PATCH 3/3] x86, boot: Change the BIOS corruption checker to scan 640K
Date: Tue, 12 Nov 2013 05:07:03 +0100 [thread overview]
Message-ID: <20131112040703.GA28410@gmail.com> (raw)
In-Reply-To: <1384215407-22288-4-git-send-email-hpa@linux.intel.com>
* H. Peter Anvin <hpa@linux.intel.com> wrote:
> From: "H. Peter Anvin" <hpa@linux.intel.com>
>
> Change the BIOS corruption checker to scan 640K if enabled. This is
> the normal amount that we otherwise would reserve with the new default
> settings; change the Kconfig help message to indicate that this is now
> intended as a diagnostic tool when one is considering enabling any
> chunk of low memory.
>
> Signed-off-by: H. Peter Anvin <hpa@linux.intel.com>
> Cc: Olof Johansson <olof@lixom.net>
> Link: http://lkml.kernel.org/r/528168CB.7070602@linux.intel.com
> ---
> arch/x86/Kconfig | 25 +++++++++++--------------
> arch/x86/kernel/check.c | 10 +++++-----
> 2 files changed, 16 insertions(+), 19 deletions(-)
>
> diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
> index 7631122..554aedd 100644
> --- a/arch/x86/Kconfig
> +++ b/arch/x86/Kconfig
> @@ -1384,24 +1384,21 @@ config HIGHPTE
> config X86_CHECK_BIOS_CORRUPTION
> bool "Check for low memory corruption"
> ---help---
> + Periodically check for memory corruption in low memory,
> + which is suspected to be caused by BIOS. Even when enabled
> + in the configuration, it is disabled at runtime. Enable it
> + by setting "memory_corruption_check=1" on the kernel command
> + line. By default it reserves and scans the low 640K of
> + memory every 60 seconds; see the
> + memory_corruption_check_size and
> memory_corruption_check_period parameters in
> Documentation/kernel-parameters.txt to adjust this.
I agree with your patches so far, and I'd suggest we go even further: I'd
say the config option is now a misnomer, it should probably be renamed to
CONFIG_X86_FORCE_RESERVE_BIOS_LOW_1MB=y or so.
Btw., should we also force-reserve the remaining bits over 640K..1MB, if
they are not marked as reserved in the memory maps, or do we already
force-reserve them somewhere?
The CONFIG_X86_BOOTPARAM_MEMORY_CORRUPTION_CHECK=y option and the
memory_corruption_check=1 boot option then allow the activation of the low
memory corrupion checker - which debug facility can be used on systems
where someone wants to live dangerously and not reserve the low 1MB of RAM
to the firmware.
Thanks,
Ingo
next prev parent reply other threads:[~2013-11-12 4:07 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2013-11-12 0:16 [RFC PATCH 0/3] x86, boot: Low memory reservation fixes H. Peter Anvin
2013-11-12 0:16 ` [RFC PATCH 1/3] x86, boot: Move setup_bios_corruption_check() later H. Peter Anvin
2013-11-12 0:16 ` [RFC PATCH 2/3] x86, boot: Change the default for X86_RESERVE_LOW to 640K, make EXPERT H. Peter Anvin
2013-11-12 0:16 ` [RFC PATCH 3/3] x86, boot: Change the BIOS corruption checker to scan 640K H. Peter Anvin
2013-11-12 4:07 ` Ingo Molnar [this message]
2013-11-12 7:19 ` H. Peter Anvin
2013-11-12 9:42 ` Ingo Molnar
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=20131112040703.GA28410@gmail.com \
--to=mingo@kernel.org \
--cc=hpa@linux.intel.com \
--cc=linux-kernel@vger.kernel.org \
--cc=olof@lixom.net \
--cc=tglx@linutronix.de \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).