[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090624131357.GA6224@elte.hu>
Date: Wed, 24 Jun 2009 15:13:57 +0200
From: Ingo Molnar <mingo@...e.hu>
To: Mike Frysinger <vapier.adi@...il.com>,
Thomas Gleixner <tglx@...utronix.de>,
Arnd Bergmann <arnd@...db.de>,
Steven Rostedt <rostedt@...dmis.org>
Cc: Linux kernel mailing list <linux-kernel@...r.kernel.org>
Subject: Re: PREEMPT_ACTIVE too low error with all asm-generic headers for
some arches
* Mike Frysinger <vapier.adi@...il.com> wrote:
> after pulling the latest mainline code, Blackfin started hitting a
> build failure like so:
> CC arch/blackfin/kernel/asm-offsets.s
> In file included from include/linux/interrupt.h:12,
> from include/linux/kernel_stat.h:8,
> from arch/blackfin/kernel/asm-offsets.c:32:
> include/linux/hardirq.h:66:2: error: #error PREEMPT_ACTIVE is too low!
> make[1]: *** [arch/blackfin/kernel/asm-offsets.s] Error 1
>
> this is because we've converted to asm-generic for most of our headers
> (including hardirq.h). originally we were defining HARDIRQ_BITS
> ourselves to 8, but then we dropped that in favor of the
> asm-generic/hardirq.h which setup a default of 8. but then they
> dropped it in favor of the linux/hardirq.h default handling ... but it
> sets it to MAX_HARDIRQ_BITS by default which is 10. which pushes
> Blackfin over the edge and into this build error.
hm, you wrote this mail to me but i havent touched asm-generic nor
blackfin in this cycle. The breakage appears to have been caused by
or at around this commit:
>From 804387a1af87f66a4b93eee230ba98f8b906b088 Mon Sep 17 00:00:00 2001
From: Arnd Bergmann <arnd@...db.de>
Date: Sun, 14 Jun 2009 22:38:11 +0200
Subject: [PATCH] asm-generic: drop HARDIRQ_BITS definition from hardirq.h
[...]
Reported-by: Mike Frysinger <vapier@...too.org>
Acked-by: Steven Rostedt <rostedt@...dmis.org>
Signed-off-by: Arnd Bergmann <arnd@...db.de>
So i've Cc:-ed those folks too.
> if we look at linux/hardirq.h, it makes this claim:
> * - bit 28 is the PREEMPT_ACTIVE flag
> if that's true, then why are we letting any arch set this define ? a
> quick survey shows that half the arches (11) are using 0x10000000 (bit
> 28) while the other half (10) are using 0x4000000 (bit 26). and then
> there is the ia64 oddity which uses bit 30. the exact value here
> shouldnt really matter across arches though should it ?
Correct - what matters is to have no collision between the fields.
> how about adding this to linux/thread_info.h:
> #ifndef PREEMPT_ACTIVE
> # ifndef PREEMPT_ACTIVE_BIT
> # define PREEMPT_ACTIVE_BIT 28
> # endif
> # define PREEMPT_ACTIVE (1 << PREEMPT_ACTIVE_BIT)
> #endif
Makes sense i guess - but do we really need that level of
#ifdef nesting? PREEMPT_ACTIVE_BIT should be the main control - with
a default to 28 if it's not set. PREEMPT_ACTIVE is then derived off
that, without any #ifdefs.
Anyway ... no objections from me in this area (and your build is
broken so i suspect you want a fix quickly), just please make the
override clean. Btw., why cannot blackfin use the defaults?
Ingo
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists