All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Randy Dunlap <randy.dunlap@oracle.com>
Cc: randrianasulu@gmail.com, Lin Ming <lin@ming.vg>,
	linux-kernel@vger.kernel.org, Ingo Molnar <mingo@elte.hu>
Subject: Re: 2.6.37-rc1 build failure
Date: Wed, 10 Nov 2010 13:59:34 +0100	[thread overview]
Message-ID: <1289393974.2191.115.camel@laptop> (raw)
In-Reply-To: <20101103213439.01d2062d.randy.dunlap@oracle.com>

On Wed, 2010-11-03 at 21:34 -0700, Randy Dunlap wrote:
> The build fails for me with the given .config file.
> It's due to selects and depends, finally comes down to HAVE_PERF_EVENTS not being
> enabled for M386 or M486.  Do you actually have a processor of that vintage?

FWIW this .config generates a _TON_ of Kconfig dep warnings..

Urgh, Kconfig hell.

config PERF_EVENTS
        bool "Kernel performance events and counters"
        default y if (PROFILING || PERF_COUNTERS)
        depends on HAVE_PERF_EVENTS
        select ANON_INODES
        select IRQ_WORK


# grep PERF_EVENTS borken-build/.config
CONFIG_PERF_EVENTS=y
CONFIG_HAVE_PERF_EVENTS_NMI=y



So we managed to get PERF_EVENTS=y even though its dependency
HAVE_PERF_EVENTS=n.


I bet that's because of:

config X86
        select HAVE_PERF_EVENTS if (!M386 && !M486)
        select PERF_EVENTS 


Ingo, should we simply do something like the below patch?

---
Subject: x86: Remove M[34]86 conditional on HAVE_PERF_EVENTS

x86 requires PERF_EVENTS because of the hardware breakpoint mess,
so don't make it conditional on M[34]86.

Signed-off-by: Peter Zijlstra <a.p.zijlstra@chello.nl>
---
 arch/x86/Kconfig |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/arch/x86/Kconfig b/arch/x86/Kconfig
index e832768..e330da2 100644
--- a/arch/x86/Kconfig
+++ b/arch/x86/Kconfig
@@ -21,7 +21,7 @@ config X86
 	select HAVE_UNSTABLE_SCHED_CLOCK
 	select HAVE_IDE
 	select HAVE_OPROFILE
-	select HAVE_PERF_EVENTS if (!M386 && !M486)
+	select HAVE_PERF_EVENTS
 	select HAVE_IRQ_WORK
 	select HAVE_IOREMAP_PROT
 	select HAVE_KPROBES


  parent reply	other threads:[~2010-11-10 12:59 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-11-03  5:32 2.6.37-rc1 build failure randrianasulu
2010-11-03  2:05 ` Lin Ming
2010-11-04  3:34   ` randrianasulu
2010-11-04  4:34     ` Randy Dunlap
2010-11-04 12:16       ` randrianasulu
2010-11-10 12:59       ` Peter Zijlstra [this message]
2010-11-10 13:24         ` Ingo Molnar
2010-11-10 17:12         ` Randy Dunlap

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=1289393974.2191.115.camel@laptop \
    --to=peterz@infradead.org \
    --cc=lin@ming.vg \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mingo@elte.hu \
    --cc=randrianasulu@gmail.com \
    --cc=randy.dunlap@oracle.com \
    /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.