From: Tejun Heo <tj@kernel.org>
To: mingo@redhat.com, tglx@linutronix.de, hpa@zytor.com,
cl@linux-foundation.org, yinghai@kernel.org
Cc: torvalds@linux-foundation.org, aarcange@redhat.com,
linux-kernel@vger.kernel.org, Tejun Heo <tj@kernel.org>
Subject: [PATCH 3/4] x86-32: Remove restrictions on ARCH_SUPPORTS_MEMORY_FAILURE
Date: Thu, 31 Mar 2011 20:02:45 +0200 [thread overview]
Message-ID: <1301594566-10139-4-git-send-email-tj@kernel.org> (raw)
In-Reply-To: <1301594566-10139-1-git-send-email-tj@kernel.org>
d949f36f18 (x86: Fix hwpoison code related build failure on 32-bit
NUMAQ) disabled ARCH_SUPPORTS_MEMORY_FAILURE on some 32bit
configurations because the extra page flag usage triggered build
failure when combined with memory section/node bits.
The root cause of build failures depending on config options is
SECTIONS_WIDTH difference depending on X86_PAE. As the previous patch
removes the problem, we can remove the restrictions on MEMORY_FAILURE.
This makes the configuration more consistent. For example,
TRANSPARENT_HUGEPAGE also consumes a page flag but didn't trigger
build failure thanks to the removal of PG_buddy and Kconfig ends up
enforcing rather arbitrary preference for TRANSPARENT_HUGEPAGE over
MEMORY_FAILURE.
Signed-off-by: Tejun Heo <tj@kernel.org>
Cc: Linus Torvalds <torvalds@linux-foundation.org>
Cc: Andrea Arcangeli <aarcange@redhat.com>
Cc: Ingo Molnar <mingo@redhat.com>
Cc: Yinghai Lu <yinghai@kernel.org>
Cc: "H. Peter Anvin" <hpa@zytor.com>
Cc: Thomas Gleixner <tglx@linutronix.de>
---
arch/x86/Kconfig | 11 +----------
1 files changed, 1 insertions(+), 10 deletions(-)
diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index 0db96ae..7f83405 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -446,16 +446,6 @@ config X86_NUMAQ
of Flat Logical. You will need a new lynxer.elf file to flash your
firmware with - send email to <Martin.Bligh@us.ibm.com>.
-config X86_SUPPORTS_MEMORY_FAILURE
- def_bool y
- # MCE code calls memory_failure():
- depends on X86_MCE
- # On 32-bit this adds too big of NODES_SHIFT and we run out of page flags:
- depends on !X86_NUMAQ
- # On 32-bit SPARSEMEM adds too big of SECTIONS_WIDTH:
- depends on X86_64 || !SPARSEMEM
- select ARCH_SUPPORTS_MEMORY_FAILURE
-
config X86_VISWS
bool "SGI 320/540 (Visual Workstation)"
depends on X86_32 && PCI && X86_MPPARSE && PCI_GODIRECT
@@ -845,6 +835,7 @@ config X86_REROUTE_FOR_BROKEN_BOOT_IRQS
config X86_MCE
bool "Machine Check / overheating reporting"
+ select ARCH_SUPPORTS_MEMORY_FAILURE
---help---
Machine Check support allows the processor to notify the
kernel if it detects a problem (e.g. overheating, data corruption).
--
1.7.1
next prev parent reply other threads:[~2011-03-31 18:03 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-03-31 18:02 [RFC PATCHSET tip:x86/mm] Remove DISCONTIGMEM support from x86-32 Tejun Heo
2011-03-31 18:02 ` [PATCH 1/4] x86: Clean up memory model related configs in arch/x86/Kconfig Tejun Heo
2011-03-31 19:48 ` Christoph Lameter
2011-03-31 18:02 ` [PATCH 2/4] x86-32: Increment SECTION_SIZE_BITS to 30 when X86_PAE Tejun Heo
2011-03-31 18:02 ` Tejun Heo [this message]
2011-03-31 18:02 ` [PATCH 4/4] x86-32, NUMA: Remove support for DISCONTIGMEM Tejun Heo
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=1301594566-10139-4-git-send-email-tj@kernel.org \
--to=tj@kernel.org \
--cc=aarcange@redhat.com \
--cc=cl@linux-foundation.org \
--cc=hpa@zytor.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mingo@redhat.com \
--cc=tglx@linutronix.de \
--cc=torvalds@linux-foundation.org \
--cc=yinghai@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.