* [patch] ppc: Fix gamecube build
From: Simon Horman @ 2010-05-13 15:25 UTC (permalink / raw)
To: linuxppc-dev, kexec; +Cc: Maxim Uvarov, Sebastian Andrzej Siewior
This fixes the kexec-build on ppc32 when
the --game-cube option is supplied to ./configure.
It seems to have bit-rotted a little.
Cc: Sebastian Andrzej Siewior <sebastian@breakpoint.cc>
Cc: Maxim Uvarov <muvarov@gmail.com>
Signed-off-by: Simon Horman <horms@verge.net.au>
Index: kexec-tools/kexec/arch/ppc/kexec-elf-ppc.c
===================================================================
--- kexec-tools.orig/kexec/arch/ppc/kexec-elf-ppc.c 2010-05-14 00:18:25.000000000 +0900
+++ kexec-tools/kexec/arch/ppc/kexec-elf-ppc.c 2010-05-14 00:20:58.000000000 +0900
@@ -162,17 +162,9 @@ int elf_ppc_load(int argc, char **argv,
unsigned long max_addr, hole_addr;
struct mem_phdr *phdr;
size_t size;
- unsigned long long *rsvmap_ptr;
- struct bootblock *bb_ptr;
- unsigned int nr_segments;
- unsigned long my_kernel, my_dt_offset;
- unsigned long my_stack, my_backup_start;
#ifdef CONFIG_PPC64
unsigned long toc_addr;
#endif
- unsigned int slave_code[256 / sizeof(unsigned int)], master_entry;
- unsigned char *seg_buf = NULL;
- off_t seg_size = 0;
#ifdef WITH_GAMECUBE
int target_is_gamecube = 1;
char *arg_buf;
@@ -183,13 +175,21 @@ int elf_ppc_load(int argc, char **argv,
unsigned char *setup_start;
uint32_t setup_size;
#else
+ unsigned long long *rsvmap_ptr;
+ struct bootblock *bb_ptr;
+ unsigned int nr_segments;
+ unsigned long my_kernel, my_dt_offset;
+ unsigned long my_stack, my_backup_start;
+ unsigned int slave_code[256 / sizeof(unsigned int)], master_entry;
+ unsigned char *seg_buf = NULL;
+ off_t seg_size = 0;
int target_is_gamecube = 0;
unsigned int addr;
unsigned long dtb_addr;
+#endif
#define FIXUP_ENTRYS (20)
char *fixup_nodes[FIXUP_ENTRYS + 1];
int cur_fixup = 0;
-#endif
int opt;
command_line = NULL;
Index: kexec-tools/kexec/arch/ppc/kexec-ppc.c
===================================================================
--- kexec-tools.orig/kexec/arch/ppc/kexec-ppc.c 2010-05-14 00:18:25.000000000 +0900
+++ kexec-tools/kexec/arch/ppc/kexec-ppc.c 2010-05-14 00:20:58.000000000 +0900
@@ -26,6 +26,11 @@
#include "config.h"
+uint64_t rmo_top;
+unsigned long long crash_base, crash_size;
+unsigned int rtas_base, rtas_size;
+int max_memory_ranges;
+
#ifdef WITH_GAMECUBE
#define MAX_MEMORY_RANGES 64
static struct memory_range memory_range[MAX_MEMORY_RANGES];
@@ -46,15 +51,11 @@ static int get_memory_ranges_gc(struct m
}
#else
static int use_new_dtb;
-int max_memory_ranges;
static int nr_memory_ranges, nr_exclude_ranges;
static struct memory_range *exclude_range;
static struct memory_range *memory_range;
static struct memory_range *base_memory_range;
static uint64_t memory_max;
-uint64_t rmo_top;
-unsigned long long crash_base, crash_size;
-unsigned int rtas_base, rtas_size;
/*
* Count the memory nodes under /proc/device-tree and populate the
^ permalink raw reply
* Re: [PATCH v2 2/2] powerpc new toolchains fix (crt.S)
From: Simon Horman @ 2010-05-13 15:00 UTC (permalink / raw)
To: Maxim Uvarov; +Cc: lists, kexec, linuxppc-dev
In-Reply-To: <20100512070849.9572.84728.stgit@muvarov>
On Wed, May 12, 2010 at 11:08:49AM +0400, Maxim Uvarov wrote:
>
> Hello everybody,
>
> Changes from previous version:
> - removed bogus hyphen from the patch;
> - move ifdefs to crt.S instead of Makefile
>
>
> Please find here patch for user land kexec-tools application. Following
> patch makes kexec-tools work for both kexec and kdump. I tested it with
> git kernel (linus-tree) and Freescale/Logic MPC8360ERDK board with
> mpc83xx_defconfig kernel config.
>
> kexec:
> kexec -l vmlinux --command-line="console= ... etc"
> kexec -e
>
> kdump:
> kexec -p vmlinux_dump --command-line="console=... etc"
> echo c > /proc/sysrq-trigger
>
> I also think that is is reasonable:
> - put GAME_CUBE specific code to separate files;
> - combine ppc and ppc64 to powerpc directory (I'm planning to do it.
> And that why in some places my patch have ifdefs for PPC64);
>
> Best regards,
> Maxim Uvarov.
Thanks,
I'm assuming that the silence that this patch set received,
in contrast to the first revision where there was some quick discussion,
means that everyone is ok with these changes. So I've gone ahead and pushed
them into the tree.
> From: Maxim Uvarov <muvarov@gmail.com>
>
> Linker does not provide some vital functions when building freestanding
> applications with a new toolchain, so we have to provide our own CRT.
>
> p.s.
> Without the CRT we won't see any build errors (since the purgatory is
> linked with --no-undefined), but the purgatory code won't work,
> 'kexec -e' will just hang the board.
>
>
> I added option to configure to keep code buildable for old toolchais.
> But there should be way to do this automatically.
I seem to have an old toolchain :-)
> Author: Anton Vorontsov <avorontsov@ru.mvista.com>
> Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
> Signed-off-by: Maxim Uvarov <muvarov@gmail.com>
^ permalink raw reply
* Re: [PATCH 4/4] trace, powerpc: Implement raw syscall tracepoints on PowerPC
From: Michael Ellerman @ 2010-05-13 12:09 UTC (permalink / raw)
To: Ian Munsie
Cc: Frederic Weisbecker, Jason Baron, linux-kernel, Steven Rostedt,
Ingo Molnar, Paul Mackerras, linuxppc-dev
In-Reply-To: <1273736594-19320-5-git-send-email-imunsie@au1.ibm.com>
[-- Attachment #1: Type: text/plain, Size: 4312 bytes --]
On Thu, 2010-05-13 at 17:43 +1000, Ian Munsie wrote:
> From: Ian Munsie <imunsie@au.ibm.com>
Hi Ian,
Just a few comments ..
> This patch implements the raw syscall tracepoints on PowerPC required
> for ftrace syscalls.
OK. It also adds a bunch of code under CONFIG_FTRACE_*, so does it
implement raw syscall tracepoints _and_ hook them up to ftrace?
> To minimise reworking existing code, I slightly re-ordered the thread
> info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
> within the 16 bits of the andi instruction's UI field.
Which andi instruction? That could use a bit more explaining.
> In the case of 64bit PowerPC, arch_syscall_addr and
> arch_syscall_match_sym_name are overridden to allow ftrace syscalls to
> work given the unusual system call table structure and symbol names that
> start with a period.
Not unusual, just different (ie. better) than x86 ;)
> diff --git a/arch/powerpc/include/asm/syscall.h b/arch/powerpc/include/asm/syscall.h
> index 23913e9..4098105 100644
> --- a/arch/powerpc/include/asm/syscall.h
> +++ b/arch/powerpc/include/asm/syscall.h
> @@ -15,6 +15,15 @@
>
> #include <linux/sched.h>
>
> +/* ftrace syscalls requires exporting the sys_call_table */
> +#ifdef CONFIG_FTRACE_SYSCALLS
> +#ifdef CONFIG_PPC64
> +extern const unsigned long long *sys_call_table;
I'm not sure why this is ULL ? UL and ULL are both 64 bits (on 64bit),
and it would save you this ifdef block and a cast in
arch_syscall_addr().
> +#else /* !CONFIG_PPC64 */
> +extern const unsigned long *sys_call_table;
> +#endif /* CONFIG_PPC64 */
> +#endif /* CONFIG_FTRACE_SYSCALLS */
> +
> static inline long syscall_get_nr(struct task_struct *task,
> struct pt_regs *regs)
> {
> diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h
> index aa9d383..e7a8af2 100644
> --- a/arch/powerpc/include/asm/thread_info.h
> +++ b/arch/powerpc/include/asm/thread_info.h
> @@ -110,7 +110,8 @@ static inline struct thread_info *current_thread_info(void)
> #define TIF_NOERROR 12 /* Force successful syscall return */
> #define TIF_NOTIFY_RESUME 13 /* callback before returning to user */
> #define TIF_FREEZE 14 /* Freezing for suspend */
> -#define TIF_RUNLATCH 15 /* Is the runlatch enabled? */
> +#define TIF_SYSCALL_TRACEPOINT 15 /* syscall tracepoint instrumentation */
> +#define TIF_RUNLATCH 16 /* Is the runlatch enabled? */
I don't grok why this is good or safe, not that it isn't but please tell
me why it is :)
> diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
> index 8773263..9c404bb 100644
> --- a/arch/powerpc/kernel/Makefile
> +++ b/arch/powerpc/kernel/Makefile
> @@ -98,6 +98,7 @@ obj64-$(CONFIG_AUDIT) += compat_audit.o
>
> obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
> obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
> +obj-$(CONFIG_FTRACE_SYSCALLS) += ftrace.o
You're following the existing pattern there, but it's a little odd.
Seems like those three config options should really all depend on
something common and that should trigger the build of ftrace.c
> diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
> index ce1f3e4..b34171e 100644
> --- a/arch/powerpc/kernel/ftrace.c
> +++ b/arch/powerpc/kernel/ftrace.c
> @@ -22,6 +22,7 @@
> #include <asm/cacheflush.h>
> #include <asm/code-patching.h>
> #include <asm/ftrace.h>
> +#include <asm/syscall.h>
>
>
> #ifdef CONFIG_DYNAMIC_FTRACE
> @@ -600,3 +601,15 @@ void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr)
> }
> }
> #endif /* CONFIG_FUNCTION_GRAPH_TRACER */
> +
> +#if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_PPC64)
Does 32-bit just work using the existing routines? Or do we not support
it on 32-bit (though that's not what your Kconfig change said).
> +unsigned long __init arch_syscall_addr(int nr)
> +{
> + return (unsigned long)sys_call_table[nr*2];
That's the cast I was referring to.
> +}
> +
> +inline bool arch_syscall_match_sym_name(const char *sym, const char *name)
> +{
> + return (!strcmp(sym + 4, name + 3));
So the +4 is to skip ".sys" and the +3 is to skip "sys" ? That could use
a comment IMHO :)
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Large physical address support on e500 platform
From: Kumar Gala @ 2010-05-13 12:05 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Aaron Pace
In-Reply-To: <F3189FB9-C04F-4C04-A6D4-25EF4D9B4BD6@kernel.crashing.org>
On Jan 25, 2010, at 11:25 AM, Kumar Gala wrote:
>=20
> On Jan 25, 2010, at 11:06 AM, Aaron Pace wrote:
>=20
>>>=20
>>> Is a simple "hello world" module sufficient to show the issue? I'll =
look into it this week.
>>>=20
>>> - k
>>=20
>> It wasn't in my situation, unfortunately. To duplicate this, I had
>> one relatively large kernel module, and then one simple 'hello world'
>> module that did nothing more than call an exported function from the
>> first module as part of its init.
>=20
> Ok, if there is a module or something you can post that reproduces the =
issue that would be extremely helpful.
I think we may now have figured this out.
- k=
^ permalink raw reply
* Re: Large physical address support on e500 platform
From: Kumar Gala @ 2010-05-13 12:01 UTC (permalink / raw)
To: Kumar Gala; +Cc: linuxppc-dev, Aaron Pace
In-Reply-To: <F3189FB9-C04F-4C04-A6D4-25EF4D9B4BD6@kernel.crashing.org>
On Jan 25, 2010, at 11:25 AM, Kumar Gala wrote:
>=20
> On Jan 25, 2010, at 11:06 AM, Aaron Pace wrote:
>=20
>>>=20
>>> Is a simple "hello world" module sufficient to show the issue? I'll =
look into it this week.
>>>=20
>>> - k
>>=20
>> It wasn't in my situation, unfortunately. To duplicate this, I had
>> one relatively large kernel module, and then one simple 'hello world'
>> module that did nothing more than call an exported function from the
>> first module as part of its init.
>=20
> Ok, if there is a module or something you can post that reproduces the =
issue that would be extremely helpful.
I think we may now have figured this out.
- k=
^ permalink raw reply
* Re: [PATCH 1/2] Fix kexec on powerpc32
From: Michael Ellerman @ 2010-05-13 11:50 UTC (permalink / raw)
To: Christian Kujau; +Cc: Maxim Uvarov, linuxppc-dev, uvarov, kexec, horms
In-Reply-To: <alpine.DEB.2.01.1005130417590.3356@bogon.housecafe.de>
[-- Attachment #1: Type: text/plain, Size: 627 bytes --]
On Thu, 2010-05-13 at 04:19 -0700, Christian Kujau wrote:
> On Wed, 12 May 2010 at 00:22, Christian Kujau wrote:
> > # kexec -e
> > Starting new kernel
> > Bye!
> >
> > ....but then the system just hung there, no more messages, I had to
> > powercycle it.
>
> Are there any debug flags (or kernel options?) I can set, to find out why
> it hangs here? Or does kexec not understand zImages?
Not really. There's extra debugging on some systems (with a hypervisor
console). I think you're on 32-bit, which means I don't really know what
I'm talking about, but I don't think zImage works - use vmlinux.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH 1/2] Fix kexec on powerpc32
From: Maxim Uvarov @ 2010-05-13 11:50 UTC (permalink / raw)
To: Christian Kujau; +Cc: kexec, uvarov, linuxppc-dev, horms
In-Reply-To: <alpine.DEB.2.01.1005130417590.3356@bogon.housecafe.de>
[-- Attachment #1: Type: text/plain, Size: 570 bytes --]
2010/5/13 Christian Kujau <lists@nerdbynature.de>
> On Wed, 12 May 2010 at 00:22, Christian Kujau wrote:
> > # kexec -e
> > Starting new kernel
> > Bye!
> >
> > ....but then the system just hung there, no more messages, I had to
> > powercycle it.
>
> Are there any debug flags (or kernel options?) I can set, to find out why
> it hangs here? Or does kexec not understand zImages?
>
>
zImage should not work with kexec. Only vmlinux.
> Thanks,
> Christian.
> --
> BOFH excuse #373:
>
> Suspicious pointer corrupted virtual machine
>
--
Best regards,
Maxim Uvarov
[-- Attachment #2: Type: text/html, Size: 1141 bytes --]
^ permalink raw reply
* Re: [RFC][PATCH 0/12] KVM, x86, ppc, asm-generic: moving dirty bitmaps to user space
From: Avi Kivity @ 2010-05-13 11:47 UTC (permalink / raw)
To: Takuya Yoshikawa
Cc: linux-arch, x86, arnd, kvm, kvm-ia64, fernando, mtosatti, agraf,
kvm-ppc, linux-kernel, linuxppc-dev, mingo, paulus, hpa, tglx,
Takuya Yoshikawa
In-Reply-To: <4BE7FB7B.5010600@oss.ntt.co.jp>
On 05/10/2010 03:26 PM, Takuya Yoshikawa wrote:
>> No doubt get.org -> get.opt is measurable, but get.opt->switch.opt is
>> problematic. Have you tried profiling to see where the time is spent
>> (well I can guess, clearing the write access from the sptes).
>
>
> Sorry but no, and I agree with your guess.
> Anyway, I want to do some profiling to confirm this guess.
>
>
> BTW, If we only think about performance improvement of time, optimized
> get(get.opt) may be enough at this stage.
>
> But if we consider the future expansion like using user allocated
> bitmaps,
> new API's introduced for switch.opt won't become waste, I think,
> because we
> need a structure to get and export bitmap addresses.
User allocated bitmaps have the advantage of reducing pinned memory.
However we have plenty more pinned memory allocated in memory slots, so
by itself, user allocated bitmaps don't justify this change.
Perhaps if we optimize memory slot write protection (I have some ideas
about this) we can make the performance improvement more pronounced.
--
error compiling committee.c: too many arguments to function
^ permalink raw reply
* Re: [PATCH 1/2] Fix kexec on powerpc32
From: Christian Kujau @ 2010-05-13 11:19 UTC (permalink / raw)
To: Maxim Uvarov; +Cc: kexec, uvarov, linuxppc-dev, horms
In-Reply-To: <4BEA5726.50806@nerdbynature.de>
On Wed, 12 May 2010 at 00:22, Christian Kujau wrote:
> # kexec -e
> Starting new kernel
> Bye!
>
> ....but then the system just hung there, no more messages, I had to
> powercycle it.
Are there any debug flags (or kernel options?) I can set, to find out why
it hangs here? Or does kexec not understand zImages?
Thanks,
Christian.
--
BOFH excuse #373:
Suspicious pointer corrupted virtual machine
^ permalink raw reply
* Re: "event-scan failed" logflood
From: pacman @ 2010-05-13 11:16 UTC (permalink / raw)
To: Benjamin Herrenschmidt; +Cc: linuxppc-dev
In-Reply-To: <1273747607.21352.185.camel@pasglop>
Benjamin Herrenschmidt writes:
>
> Well, first it should be called once per second, not 60 times per
> second, so something is wrong there...
Actually I think it was happening a lot more than 60 times per second, and
klogd was losing most of the messages because they came too fast. When
running the new kernel, vmstat shows 170000 context switches per second (and
CPU usage never going below 5%) even when everything should be idle.
My next experiment was to hack rtas_init to return 0 unconditionally. Now
everything still runs fine, and the context switches per second are back down
in the 2-digit range.
>
> Then, it wouldn't surprise me if the Pegasos RTAS didn't implement
> the event scan properly. Maybe we failed silently before that ? I
> doubt it's necessary there anyways.
If I'm reading things correctly, rtas-event-scan-rate is the key to the
frequency of attempts. And rtasd.c didn't expect this:
$ od -t x1 /proc/device-tree/rtas/rtas-event-scan-rate
0000000 00 00 00 00
0000004
--
Alan Curry
^ permalink raw reply
* Re: "event-scan failed" logflood
From: Benjamin Herrenschmidt @ 2010-05-13 10:46 UTC (permalink / raw)
To: michael; +Cc: pacman, linuxppc-dev
In-Reply-To: <1273730685.25436.66.camel@concordia>
On Thu, 2010-05-13 at 16:04 +1000, Michael Ellerman wrote:
> It's probably caused by 3d541c4b7f6efd55a98189afd1b2f1c9d048c1b3.
>
> Is Pegasos a chrp, I can't remember. It did get called in the old chrp
> code, and the comments suggest you have to call it.
>
> It's not obvious looking at the diff why it would be failing now but
> didn't previously.
Well, first it should be called once per second, not 60 times per
second, so something is wrong there...
Then, it wouldn't surprise me if the Pegasos RTAS didn't implement
the event scan properly. Maybe we failed silently before that ? I
doubt it's necessary there anyways.
It would be relatively easy to avoid starting the event scan on a
pegasos, I think we have a _chrp_type variable that can be tested
for that.
Cheers,
Ben.
^ permalink raw reply
* [PATCH 4/4] trace, powerpc: Implement raw syscall tracepoints on PowerPC
From: Ian Munsie @ 2010-05-13 7:43 UTC (permalink / raw)
To: linux-kernel
Cc: Frederic Weisbecker, Jason Baron, Steven Rostedt, Ingo Molnar,
Paul Mackerras, Ian Munsie, linuxppc-dev
In-Reply-To: <1273736594-19320-1-git-send-email-imunsie@au1.ibm.com>
From: Ian Munsie <imunsie@au.ibm.com>
This patch implements the raw syscall tracepoints on PowerPC required
for ftrace syscalls.
To minimise reworking existing code, I slightly re-ordered the thread
info flags such that the new TIF_SYSCALL_TRACEPOINT bit would still fit
within the 16 bits of the andi instruction's UI field.
In the case of 64bit PowerPC, arch_syscall_addr and
arch_syscall_match_sym_name are overridden to allow ftrace syscalls to
work given the unusual system call table structure and symbol names that
start with a period.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
arch/powerpc/Kconfig | 1 +
arch/powerpc/include/asm/syscall.h | 9 +++++++++
arch/powerpc/include/asm/thread_info.h | 7 +++++--
arch/powerpc/kernel/Makefile | 1 +
arch/powerpc/kernel/ftrace.c | 13 +++++++++++++
arch/powerpc/kernel/ptrace.c | 10 ++++++++++
6 files changed, 39 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/Kconfig b/arch/powerpc/Kconfig
index c4c4549..41e2f3e 100644
--- a/arch/powerpc/Kconfig
+++ b/arch/powerpc/Kconfig
@@ -141,6 +141,7 @@ config PPC
select GENERIC_ATOMIC64 if PPC32
select HAVE_PERF_EVENTS
select HAVE_REGS_AND_STACK_ACCESS_API
+ select HAVE_SYSCALL_TRACEPOINTS
config EARLY_PRINTK
bool
diff --git a/arch/powerpc/include/asm/syscall.h b/arch/powerpc/include/asm/syscall.h
index 23913e9..4098105 100644
--- a/arch/powerpc/include/asm/syscall.h
+++ b/arch/powerpc/include/asm/syscall.h
@@ -15,6 +15,15 @@
#include <linux/sched.h>
+/* ftrace syscalls requires exporting the sys_call_table */
+#ifdef CONFIG_FTRACE_SYSCALLS
+#ifdef CONFIG_PPC64
+extern const unsigned long long *sys_call_table;
+#else /* !CONFIG_PPC64 */
+extern const unsigned long *sys_call_table;
+#endif /* CONFIG_PPC64 */
+#endif /* CONFIG_FTRACE_SYSCALLS */
+
static inline long syscall_get_nr(struct task_struct *task,
struct pt_regs *regs)
{
diff --git a/arch/powerpc/include/asm/thread_info.h b/arch/powerpc/include/asm/thread_info.h
index aa9d383..e7a8af2 100644
--- a/arch/powerpc/include/asm/thread_info.h
+++ b/arch/powerpc/include/asm/thread_info.h
@@ -110,7 +110,8 @@ static inline struct thread_info *current_thread_info(void)
#define TIF_NOERROR 12 /* Force successful syscall return */
#define TIF_NOTIFY_RESUME 13 /* callback before returning to user */
#define TIF_FREEZE 14 /* Freezing for suspend */
-#define TIF_RUNLATCH 15 /* Is the runlatch enabled? */
+#define TIF_SYSCALL_TRACEPOINT 15 /* syscall tracepoint instrumentation */
+#define TIF_RUNLATCH 16 /* Is the runlatch enabled? */
/* as above, but as bit values */
#define _TIF_SYSCALL_TRACE (1<<TIF_SYSCALL_TRACE)
@@ -127,8 +128,10 @@ static inline struct thread_info *current_thread_info(void)
#define _TIF_NOERROR (1<<TIF_NOERROR)
#define _TIF_NOTIFY_RESUME (1<<TIF_NOTIFY_RESUME)
#define _TIF_FREEZE (1<<TIF_FREEZE)
+#define _TIF_SYSCALL_TRACEPOINT (1<<TIF_SYSCALL_TRACEPOINT)
#define _TIF_RUNLATCH (1<<TIF_RUNLATCH)
-#define _TIF_SYSCALL_T_OR_A (_TIF_SYSCALL_TRACE|_TIF_SYSCALL_AUDIT|_TIF_SECCOMP)
+#define _TIF_SYSCALL_T_OR_A (_TIF_SYSCALL_TRACE | _TIF_SYSCALL_AUDIT | \
+ _TIF_SECCOMP | _TIF_SYSCALL_TRACEPOINT)
#define _TIF_USER_WORK_MASK (_TIF_SIGPENDING | _TIF_NEED_RESCHED | \
_TIF_NOTIFY_RESUME)
diff --git a/arch/powerpc/kernel/Makefile b/arch/powerpc/kernel/Makefile
index 8773263..9c404bb 100644
--- a/arch/powerpc/kernel/Makefile
+++ b/arch/powerpc/kernel/Makefile
@@ -98,6 +98,7 @@ obj64-$(CONFIG_AUDIT) += compat_audit.o
obj-$(CONFIG_DYNAMIC_FTRACE) += ftrace.o
obj-$(CONFIG_FUNCTION_GRAPH_TRACER) += ftrace.o
+obj-$(CONFIG_FTRACE_SYSCALLS) += ftrace.o
obj-$(CONFIG_PERF_EVENTS) += perf_callchain.o
obj-$(CONFIG_PPC_PERF_CTRS) += perf_event.o
diff --git a/arch/powerpc/kernel/ftrace.c b/arch/powerpc/kernel/ftrace.c
index ce1f3e4..b34171e 100644
--- a/arch/powerpc/kernel/ftrace.c
+++ b/arch/powerpc/kernel/ftrace.c
@@ -22,6 +22,7 @@
#include <asm/cacheflush.h>
#include <asm/code-patching.h>
#include <asm/ftrace.h>
+#include <asm/syscall.h>
#ifdef CONFIG_DYNAMIC_FTRACE
@@ -600,3 +601,15 @@ void prepare_ftrace_return(unsigned long *parent, unsigned long self_addr)
}
}
#endif /* CONFIG_FUNCTION_GRAPH_TRACER */
+
+#if defined(CONFIG_FTRACE_SYSCALLS) && defined(CONFIG_PPC64)
+unsigned long __init arch_syscall_addr(int nr)
+{
+ return (unsigned long)sys_call_table[nr*2];
+}
+
+inline bool arch_syscall_match_sym_name(const char *sym, const char *name)
+{
+ return (!strcmp(sym + 4, name + 3));
+}
+#endif /* CONFIG_FTRACE_SYSCALLS && CONFIG_PPC64 */
diff --git a/arch/powerpc/kernel/ptrace.c b/arch/powerpc/kernel/ptrace.c
index 7a0c019..eb7eeb8 100644
--- a/arch/powerpc/kernel/ptrace.c
+++ b/arch/powerpc/kernel/ptrace.c
@@ -29,6 +29,7 @@
#include <linux/signal.h>
#include <linux/seccomp.h>
#include <linux/audit.h>
+#include <trace/syscall.h>
#ifdef CONFIG_PPC32
#include <linux/module.h>
#endif
@@ -38,6 +39,9 @@
#include <asm/pgtable.h>
#include <asm/system.h>
+#define CREATE_TRACE_POINTS
+#include <trace/events/syscalls.h>
+
/*
* The parameter save area on the stack is used to store arguments being passed
* to callee function and is located at fixed offset from stack pointer.
@@ -1615,6 +1619,9 @@ long do_syscall_trace_enter(struct pt_regs *regs)
*/
ret = -1L;
+ if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
+ trace_sys_enter(regs, regs->gpr[0]);
+
if (unlikely(current->audit_context)) {
#ifdef CONFIG_PPC64
if (!test_thread_flag(TIF_32BIT))
@@ -1643,6 +1650,9 @@ void do_syscall_trace_leave(struct pt_regs *regs)
audit_syscall_exit((regs->ccr&0x10000000)?AUDITSC_FAILURE:AUDITSC_SUCCESS,
regs->result);
+ if (unlikely(test_thread_flag(TIF_SYSCALL_TRACEPOINT)))
+ trace_sys_exit(regs, regs->result);
+
step = test_thread_flag(TIF_SINGLESTEP);
if (step || test_thread_flag(TIF_SYSCALL_TRACE))
tracehook_report_syscall_exit(regs, step);
--
1.7.1
^ permalink raw reply related
* [PATCH 3/4] ftrace syscalls: Allow arch specific syscall symbol matching
From: Ian Munsie @ 2010-05-13 7:43 UTC (permalink / raw)
To: linux-kernel
Cc: Frederic Weisbecker, Jason Baron, Steven Rostedt, Ingo Molnar,
Paul Mackerras, Ian Munsie, linuxppc-dev
In-Reply-To: <1273736594-19320-1-git-send-email-imunsie@au1.ibm.com>
From: Ian Munsie <imunsie@au1.ibm.com>
Some architectures have unusual symbol names and the generic code to
match the symbol name with the function name for the syscall metadata
will fail. For example, symbols on PPC64 start with a period and the
generic code will fail to match them.
This patch splits out the match logic into a standalone weak function
that can be overridden on archs with unusual symbol names.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
Documentation/trace/ftrace-design.txt | 3 +++
include/linux/ftrace.h | 1 +
kernel/trace/trace_syscalls.c | 19 ++++++++++++-------
3 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt
index 8369a1c..3936d5f 100644
--- a/Documentation/trace/ftrace-design.txt
+++ b/Documentation/trace/ftrace-design.txt
@@ -247,6 +247,9 @@ You need very few things to get the syscalls tracing in an arch.
- If the system call table on this arch is more complicated than a simple array
of addresses of the system calls, implement an arch_syscall_addr to return
the address of a given system call.
+- If the symbol names of the system calls do not match the function names on
+ this arch, implement an arch_syscall_match_sym_name with the appropriate
+ logic to return true if the function name corresponds with the symbol name.
- Tag this arch as HAVE_SYSCALL_TRACEPOINTS.
diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
index e0ae83b..26ad1f5 100644
--- a/include/linux/ftrace.h
+++ b/include/linux/ftrace.h
@@ -534,6 +534,7 @@ static inline void trace_hw_branch_oops(void) {}
#ifdef CONFIG_FTRACE_SYSCALLS
unsigned long arch_syscall_addr(int nr);
+bool arch_syscall_match_sym_name(const char *sym, const char *name);
#endif /* CONFIG_FTRACE_SYSCALLS */
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 1c231d0..ebbc74d 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -32,13 +32,7 @@ static struct syscall_metadata *find_syscall_meta(unsigned long syscall)
kallsyms_lookup(syscall, NULL, NULL, NULL, str);
for ( ; start < stop; start++) {
- /*
- * Only compare after the "sys" prefix. Archs that use
- * syscall wrappers may have syscalls symbols aliases prefixed
- * with "SyS" instead of "sys", leading to an unwanted
- * mismatch.
- */
- if (start->name && !strcmp(start->name + 3, str + 3))
+ if (start->name && arch_syscall_match_sym_name(str, start->name))
return start;
}
return NULL;
@@ -408,6 +402,17 @@ unsigned long __init __weak arch_syscall_addr(int nr)
return (unsigned long)sys_call_table[nr];
}
+bool __weak arch_syscall_match_sym_name(const char *sym, const char *name)
+{
+ /*
+ * Only compare after the "sys" prefix. Archs that use
+ * syscall wrappers may have syscalls symbols aliases prefixed
+ * with "SyS" instead of "sys", leading to an unwanted
+ * mismatch.
+ */
+ return (!strcmp(sym + 3, name + 3));
+}
+
int __init init_ftrace_syscalls(void)
{
struct syscall_metadata *meta;
--
1.7.1
^ permalink raw reply related
* [PATCH 2/4] ftrace syscalls: Make arch_syscall_addr weak
From: Ian Munsie @ 2010-05-13 7:43 UTC (permalink / raw)
To: linux-kernel
Cc: Frederic Weisbecker, Jason Baron, Steven Rostedt, Ingo Molnar,
Paul Mackerras, Ian Munsie, linuxppc-dev
In-Reply-To: <1273736594-19320-1-git-send-email-imunsie@au1.ibm.com>
From: Ian Munsie <imunsie@au1.ibm.com>
Some architectures use non-trivial system call tables and will not work
with the generic arch_syscall_addr code. For example, PowerPC64 uses a
table of twin long longs.
This patch makes the generic arch_syscall_addr weak to allow
architectures with non-trivial system call tables to override it.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
Documentation/trace/ftrace-design.txt | 3 +++
kernel/trace/trace_syscalls.c | 2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Documentation/trace/ftrace-design.txt b/Documentation/trace/ftrace-design.txt
index f1f81af..8369a1c 100644
--- a/Documentation/trace/ftrace-design.txt
+++ b/Documentation/trace/ftrace-design.txt
@@ -244,6 +244,9 @@ You need very few things to get the syscalls tracing in an arch.
- Support the TIF_SYSCALL_TRACEPOINT thread flags.
- Put the trace_sys_enter() and trace_sys_exit() tracepoints calls from ptrace
in the ptrace syscalls tracing path.
+- If the system call table on this arch is more complicated than a simple array
+ of addresses of the system calls, implement an arch_syscall_addr to return
+ the address of a given system call.
- Tag this arch as HAVE_SYSCALL_TRACEPOINTS.
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 732f021..1c231d0 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -403,7 +403,7 @@ int init_syscall_trace(struct ftrace_event_call *call)
return id;
}
-unsigned long __init arch_syscall_addr(int nr)
+unsigned long __init __weak arch_syscall_addr(int nr)
{
return (unsigned long)sys_call_table[nr];
}
--
1.7.1
^ permalink raw reply related
* [PATCH 1/4] ftrace syscalls: don't add events for unmapped syscalls
From: Ian Munsie @ 2010-05-13 7:43 UTC (permalink / raw)
To: linux-kernel
Cc: Frederic Weisbecker, Jason Baron, Steven Rostedt, Ingo Molnar,
Paul Mackerras, Ian Munsie, linuxppc-dev
In-Reply-To: <1273736594-19320-1-git-send-email-imunsie@au1.ibm.com>
From: Ian Munsie <imunsie@au1.ibm.com>
FTRACE_SYSCALLS would create events for each and every system call, even
if it had failed to map the system call's name with it's number. This
resulted in a number of events being created that would not behave as
expected.
This could happen, for example, on architectures who's symbol names are
unusual and will not match the system call name. It could also happen
with system calls which were mapped to sys_ni_syscall.
This patch changes the default system call number in the metadata to -1.
If the system call name from the metadata is not successfully mapped to
a system call number during boot, than the event initialisation routine
will now return an error, preventing the event from being created.
Signed-off-by: Ian Munsie <imunsie@au1.ibm.com>
---
include/linux/syscalls.h | 2 ++
kernel/trace/trace_syscalls.c | 8 ++++++++
2 files changed, 10 insertions(+), 0 deletions(-)
diff --git a/include/linux/syscalls.h b/include/linux/syscalls.h
index 057929b..a970c24 100644
--- a/include/linux/syscalls.h
+++ b/include/linux/syscalls.h
@@ -186,6 +186,7 @@ struct perf_event_attr;
__attribute__((section("__syscalls_metadata"))) \
__syscall_meta_##sname = { \
.name = "sys"#sname, \
+ .syscall_nr = -1, /* Filled in at boot */ \
.nb_args = nb, \
.types = types_##sname, \
.args = args_##sname, \
@@ -201,6 +202,7 @@ struct perf_event_attr;
__attribute__((section("__syscalls_metadata"))) \
__syscall_meta__##sname = { \
.name = "sys_"#sname, \
+ .syscall_nr = -1, /* Filled in at boot */ \
.nb_args = 0, \
.enter_event = &event_enter__##sname, \
.exit_event = &event_exit__##sname, \
diff --git a/kernel/trace/trace_syscalls.c b/kernel/trace/trace_syscalls.c
index 4d6d711..732f021 100644
--- a/kernel/trace/trace_syscalls.c
+++ b/kernel/trace/trace_syscalls.c
@@ -381,6 +381,14 @@ void unreg_event_syscall_exit(struct ftrace_event_call *call)
int init_syscall_trace(struct ftrace_event_call *call)
{
int id;
+ int num;
+
+ num = ((struct syscall_metadata *)call->data)->syscall_nr;
+ if (num < 0 || num >= NR_syscalls) {
+ pr_debug("syscall %s metadata not mapped, disabling ftrace event\n",
+ ((struct syscall_metadata *)call->data)->name);
+ return -ENOSYS;
+ }
if (set_syscall_print_fmt(call) < 0)
return -ENOMEM;
--
1.7.1
^ permalink raw reply related
* ftrace syscalls, PowerPC: Fixes and PowerPC raw syscall tracepoint implementation
From: Ian Munsie @ 2010-05-13 7:43 UTC (permalink / raw)
To: linux-kernel
Cc: Frederic Weisbecker, Jason Baron, Steven Rostedt, Ingo Molnar,
Paul Mackerras, linuxppc-dev
This patch series implements raw system call tracepoints on PowerPC that can be
used with ftrace and perf. Some problems with the generic ftrace syscall
tracepoint code have also been addressed.
The patches are based upon Ben's powerpc/next tree merged with tip/tracing/core
Patch #1 removes all ftrace syscall events that fail to map the system call
name from the system call metadata with the system call's number, preventing
the events which will not work from showing up in perf list and removing them
from /sys/kernel/debug/tracing/events/syscalls.
Patches #2 and #3 allow for archs with unusual system call tables (#2) or
unusual symbol names (#3) to override the appropriate functions so that they
can still work with ftrace syscalls.
Patch #4 implements the actual raw system call tracepoints that ftrace syscalls
builds upon, allowing all of the system calls to be used with the raw_syscalls
events category and most to be used with the syscalls category.
Not all the raw_syscalls are currently mapped to ftrace syscalls - the syscalls
defined in /arch/powerpc/include/asm/syscalls.h do not use the SYSCALL_DEFINE
class of macros and as such have no meta data, likewise some of the ppc_*
syscalls have assembly wrappers. These are on their way, but I wanted to put
the work I have done so far out first.
Some of those syscalls have different return types than the __SYSCALL_DEFINE
macro uses (unsigned long, int, time_t) and some have different prefixes (ppc,
ppc64) - I didn't particularly want to change them straight over without asking
the list first, and I certainly don't want to change the return types. I see
that Jason Baron ran into similar issues, but his "add compat syscall support"
patches have yet to be merged, and do not tackle the differing return types.
^ permalink raw reply
* Re: "event-scan failed" logflood
From: Michael Ellerman @ 2010-05-13 6:04 UTC (permalink / raw)
To: pacman; +Cc: linuxppc-dev
In-Reply-To: <20100513041329.1972.qmail@kosh.dhis.org>
[-- Attachment #1: Type: text/plain, Size: 995 bytes --]
On Wed, 2010-05-12 at 23:13 -0500, pacman@kosh.dhis.org wrote:
> I upgraded the kernel on my Pegasos from 2.6.32 to 2.6.33 and now it sends
> the message "event-scan failed" to the kernel log about 60 times per second
> as long as it's running.
>
> The message comes from arch/powerpc/kernel/rtasd.c but I don't know what's
> going on in there so I can't say much more about it.
>
> How may I help find the cause of this problem?
>
> (Or alternatively: what is the correct way to disable this "event-scan"? I
> suspect it's not really necessary since it didn't exist in the previous
> kernel version, and the system is running perfectly aside from the error
> message flood.)
>
It's probably caused by 3d541c4b7f6efd55a98189afd1b2f1c9d048c1b3.
Is Pegasos a chrp, I can't remember. It did get called in the old chrp
code, and the comments suggest you have to call it.
It's not obvious looking at the diff why it would be failing now but
didn't previously.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* "event-scan failed" logflood
From: pacman @ 2010-05-13 4:13 UTC (permalink / raw)
To: linuxppc-dev
I upgraded the kernel on my Pegasos from 2.6.32 to 2.6.33 and now it sends
the message "event-scan failed" to the kernel log about 60 times per second
as long as it's running.
The message comes from arch/powerpc/kernel/rtasd.c but I don't know what's
going on in there so I can't say much more about it.
How may I help find the cause of this problem?
(Or alternatively: what is the correct way to disable this "event-scan"? I
suspect it's not really necessary since it didn't exist in the previous
kernel version, and the system is running perfectly aside from the error
message flood.)
--
Alan Curry
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Benjamin Herrenschmidt @ 2010-05-13 1:46 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev list, Andrew Morton, Linux Kernel list
In-Reply-To: <1273660604.21352.123.camel@pasglop>
Hi Linus !
I've added to my merge branch Kumar's swiotlb fix. Here's the updated
pull request.
Thanks !
Cheers,
Ben.
The following changes since commit cea0d767c29669bf89f86e4aee46ef462d2ebae8:
Linus Torvalds (1):
Merge branch 'hwmon-for-linus' of git://git.kernel.org/.../jdelvare/staging
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/benh/powerpc.git merge
Benjamin Herrenschmidt (1):
Merge commit 'kumar/merge' into merge
Kumar Gala (1):
powerpc/swiotlb: Fix off by one in determining boundary of which ops to use
Paul Mackerras (1):
powerpc/perf_event: Fix oops due to perf_event_do_pending call
arch/powerpc/include/asm/hw_irq.h | 38 -----------------------
arch/powerpc/kernel/asm-offsets.c | 1 -
arch/powerpc/kernel/dma-swiotlb.c | 5 ++-
arch/powerpc/kernel/entry_64.S | 9 -----
arch/powerpc/kernel/irq.c | 6 ----
arch/powerpc/kernel/time.c | 60 +++++++++++++++++++++++++++++-------
6 files changed, 51 insertions(+), 68 deletions(-)
^ permalink raw reply
* Re: [PATCH] [POWEPC] crashdump: do not fail on null pointer dereferencing
From: Michael Ellerman @ 2010-05-13 1:25 UTC (permalink / raw)
To: Vitaly Wool; +Cc: Maxim Uvarov, uvarov, linuxppc-dev, linux-kernel
In-Reply-To: <AANLkTinTprEzXRIFeJfu6TEvPqj24UBjrrZN3MtZD6LH@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 681 bytes --]
On Tue, 2010-05-11 at 18:02 +0200, Vitaly Wool wrote:
> Hi,
>
> > diff --git a/arch/powerpc/kernel/crash.c b/arch/powerpc/kernel/crash.c
> > index 6f4613d..341d8af 100644
> > --- a/arch/powerpc/kernel/crash.c
> > +++ b/arch/powerpc/kernel/crash.c
> > @@ -375,6 +375,9 @@ void default_machine_crash_shutdown(struct pt_regs *regs)
> > for_each_irq(i) {
> > struct irq_desc *desc = irq_to_desc(i);
> >
> > + if (!desc || !desc->chip || !desc->chip->eoi)
> > + continue;
> > +
Actually almost certain that desc will be NULL. When CONFIG_SPARSE_IRQ=y
(the default), irq_desc's are allocated lazily.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: Config Items appearing twice in same Kconfig file?
From: Michael Ellerman @ 2010-05-13 1:08 UTC (permalink / raw)
To: Christoph Egger
Cc: linux-ia64, vamos, Jesse Barnes, Timo Teras, Chen Liqin,
Paul Mackerras, H. Peter Anvin, Lennox Wu, Jesper Nilsson,
Pekka Savola (ipv6), x86, James Morris, Ingo Molnar,
Alexey Kuznetsov, Matt Turner, Fenghua Yu, Mike Frysinger,
Arnd Bergmann, Graf Yang, Mikael Starvik, Ivan Kokshaysky,
Thomas Gleixner, Arjan van de Ven, Richard Henderson,
Karsten Keil, Tony Luck, linux-cris-kernel, linuxppc-dev,
Hideaki YOSHIFUJI, netdev, linux-kernel, Patrick McHardy,
FUJITA Tomonori, linux-alpha, uclinux-dist-devel, Andrew Morton,
David S. Miller
In-Reply-To: <20100512144017.GA722@faui48a.informatik.uni-erlangen.de>
[-- Attachment #1: Type: text/plain, Size: 994 bytes --]
On Wed, 2010-05-12 at 16:40 +0200, Christoph Egger wrote:
> Just noticed it might have been worth adding the output so everyone
> out there doesn't ned to grep through his tree for reference:
>
> % grep ^config **/Kconfig* | sort | uniq -dc
That didn't actually work for me?
> 2 arch/powerpc/Kconfig:config KERNEL_START
> 2 arch/powerpc/Kconfig:config PAGE_OFFSET
> 2 arch/powerpc/Kconfig:config PHYSICAL_START
> 2 arch/powerpc/Kconfig:config RELOCATABLE
The duplication of these is caused by the second definitions being
inside an "if PPC64" block.
For PAGE_OFFSET and KERNEL_START we want the 2nd definitions, the
default value is different between 32 & 64 bit.
For RELOCATABLE it's a little weird, but we want the 2nd definition
because the depends condition is different between 32 & 64bit - though
they could probably be merged.
I don't really see why we need two versions of PHYSICAL_START.
cheers
[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 198 bytes --]
^ permalink raw reply
* Re: [PATCH] powerpc: fix register_power_pmu() section mismatch warning
From: Paul Mackerras @ 2010-05-13 0:09 UTC (permalink / raw)
To: Albert Herranz; +Cc: linuxppc-dev
In-Reply-To: <1273687486-13381-1-git-send-email-albert_herranz@yahoo.es>
On Wed, May 12, 2010 at 08:04:46PM +0200, Albert Herranz wrote:
> Add missing __cpuinit annotations to fix a bunch of warnings like the one
> shown below when building a kernel for the PowerPC architecture with
> CONFIG_DEBUG_SECTION_MISMATCH=y.
>
> WARNING: arch/powerpc/kernel/built-in.o(.text+0x11c72): Section mismatch in reference from the function register_power_pmu() to the variable .cpuinit.data:power_pmu_notifier_nb.23552
> The function register_power_pmu() references
> the variable __cpuinitdata power_pmu_notifier_nb.23552.
> This is often because register_power_pmu lacks a __cpuinitdata
> annotation or the annotation of power_pmu_notifier_nb.23552 is wrong.
Hmmm, I would think these things could be just plain __init, not
__cpuinit. They're not called on cpu hotplug events.
Paul.
^ permalink raw reply
* [PATCH] powerpc: fix register_power_pmu() section mismatch warning
From: Albert Herranz @ 2010-05-12 18:04 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Albert Herranz
Add missing __cpuinit annotations to fix a bunch of warnings like the one
shown below when building a kernel for the PowerPC architecture with
CONFIG_DEBUG_SECTION_MISMATCH=y.
WARNING: arch/powerpc/kernel/built-in.o(.text+0x11c72): Section mismatch in reference from the function register_power_pmu() to the variable .cpuinit.data:power_pmu_notifier_nb.23552
The function register_power_pmu() references
the variable __cpuinitdata power_pmu_notifier_nb.23552.
This is often because register_power_pmu lacks a __cpuinitdata
annotation or the annotation of power_pmu_notifier_nb.23552 is wrong.
Signed-off-by: Albert Herranz <albert_herranz@yahoo.es>
---
arch/powerpc/kernel/mpc7450-pmu.c | 2 +-
arch/powerpc/kernel/perf_event.c | 2 +-
2 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/arch/powerpc/kernel/mpc7450-pmu.c b/arch/powerpc/kernel/mpc7450-pmu.c
index 09d7202..3982bfa 100644
--- a/arch/powerpc/kernel/mpc7450-pmu.c
+++ b/arch/powerpc/kernel/mpc7450-pmu.c
@@ -405,7 +405,7 @@ struct power_pmu mpc7450_pmu = {
.cache_events = &mpc7450_cache_events,
};
-static int init_mpc7450_pmu(void)
+static int __cpuinit init_mpc7450_pmu(void)
{
if (!cur_cpu_spec->oprofile_cpu_type ||
strcmp(cur_cpu_spec->oprofile_cpu_type, "ppc/7450"))
diff --git a/arch/powerpc/kernel/perf_event.c b/arch/powerpc/kernel/perf_event.c
index 08460a2..6b70834 100644
--- a/arch/powerpc/kernel/perf_event.c
+++ b/arch/powerpc/kernel/perf_event.c
@@ -1314,7 +1314,7 @@ power_pmu_notifier(struct notifier_block *self, unsigned long action, void *hcpu
return NOTIFY_OK;
}
-int register_power_pmu(struct power_pmu *pmu)
+int __cpuinit register_power_pmu(struct power_pmu *pmu)
{
if (ppmu)
return -EBUSY; /* something's already registered */
--
1.6.3.3
^ permalink raw reply related
* [PATCH] Update smt_enabled=X handling for cores with more than two threads
From: Nathan Fontenot @ 2010-05-12 14:50 UTC (permalink / raw)
To: linuxppc-dev
This patch updates the handling of the smt-enabled=X boot option to handle
settings on systems with more than two threads per core. This change involves
moving all of the handling of the boot option to the check_smt_enabled()
routine and the calling of this routine in setup_system() until after the
smp_setup_cpu_maps() call. This is done so that we can use the
threads_per_core variable when validating the smt boot option specified.
Signed-off-by: Nathan Fontenot<nfont@austin.ibm.com>
---
arch/powerpc/kernel/setup_64.c | 61 ++++++++++++++++++++---------------
arch/powerpc/platforms/pseries/smp.c | 11 ++++--
2 files changed, 42 insertions(+), 30 deletions(-)
Index: powerpc/arch/powerpc/kernel/setup_64.c
===================================================================
--- powerpc.orig/arch/powerpc/kernel/setup_64.c 2010-05-12 08:33:38.000000000 -0500
+++ powerpc/arch/powerpc/kernel/setup_64.c 2010-05-12 08:48:10.000000000 -0500
@@ -95,7 +95,7 @@
#ifdef CONFIG_SMP
-static int smt_enabled_cmdline;
+static char *smt_enabled_cmdline;
/* Look for ibm,smt-enabled OF option */
static void check_smt_enabled(void)
@@ -103,37 +103,46 @@
struct device_node *dn;
const char *smt_option;
- /* Allow the command line to overrule the OF option */
- if (smt_enabled_cmdline)
- return;
-
- dn = of_find_node_by_path("/options");
+ /* Default to enabling all threads */
+ smt_enabled_at_boot = threads_per_core;
- if (dn) {
- smt_option = of_get_property(dn, "ibm,smt-enabled", NULL);
+ /* Allow the command line to overrule the OF option */
+ if (smt_enabled_cmdline) {
+ if (!strcmp(smt_enabled_cmdline, "on"))
+ smt_enabled_at_boot = threads_per_core;
+ else if (!strcmp(smt_enabled_cmdline, "off"))
+ smt_enabled_at_boot = 0;
+ else {
+ long smt;
+ int rc;
+
+ rc = strict_strtol(smt_enabled_cmdline, 10,&smt);
+ if (!rc)
+ smt_enabled_at_boot =
+ min(threads_per_core, (int)smt);
+ }
+ } else {
+ dn = of_find_node_by_path("/options");
+ if (dn) {
+ smt_option = of_get_property(dn, "ibm,smt-enabled",
+ NULL);
+
+ if (smt_option) {
+ if (!strcmp(smt_option, "on"))
+ smt_enabled_at_boot = threads_per_core;
+ else if (!strcmp(smt_option, "off"))
+ smt_enabled_at_boot = 0;
+ }
- if (smt_option) {
- if (!strcmp(smt_option, "on"))
- smt_enabled_at_boot = 1;
- else if (!strcmp(smt_option, "off"))
- smt_enabled_at_boot = 0;
- }
- }
+ of_node_put(dn);
+ }
+ }
}
/* Look for smt-enabled= cmdline option */
static int __init early_smt_enabled(char *p)
{
- smt_enabled_cmdline = 1;
-
- if (!p)
- return 0;
-
- if (!strcmp(p, "on") || !strcmp(p, "1"))
- smt_enabled_at_boot = 1;
- else if (!strcmp(p, "off") || !strcmp(p, "0"))
- smt_enabled_at_boot = 0;
-
+ smt_enabled_cmdline = p;
return 0;
}
early_param("smt-enabled", early_smt_enabled);
@@ -390,8 +399,8 @@
*/
xmon_setup();
- check_smt_enabled();
smp_setup_cpu_maps();
+ check_smt_enabled();
#ifdef CONFIG_SMP
/* Release secondary cpus out of their spinloops at 0x60 now that
Index: powerpc/arch/powerpc/platforms/pseries/smp.c
===================================================================
--- powerpc.orig/arch/powerpc/platforms/pseries/smp.c 2010-05-12 08:33:38.000000000 -0500
+++ powerpc/arch/powerpc/platforms/pseries/smp.c 2010-05-12 08:36:09.000000000 -0500
@@ -154,10 +154,13 @@
/* Special case - we inhibit secondary thread startup
* during boot if the user requests it.
*/
- if (system_state< SYSTEM_RUNNING&&
- cpu_has_feature(CPU_FTR_SMT)&&
- !smt_enabled_at_boot&& cpu_thread_in_core(nr) != 0)
- return 0;
+ if (system_state< SYSTEM_RUNNING&& cpu_has_feature(CPU_FTR_SMT)) {
+ if (!smt_enabled_at_boot&& cpu_thread_in_core(nr) != 0)
+ return 0;
+ if (smt_enabled_at_boot
+ && cpu_thread_in_core(nr)>= smt_enabled_at_boot)
+ return 0;
+ }
return 1;
}
^ permalink raw reply
* Config Items appearing twice in same Kconfig file?
From: Christoph Egger @ 2010-05-12 14:34 UTC (permalink / raw)
To: Richard Henderson, Ivan Kokshaysky, Matt Turner, Andrew Morton,
FUJITA Tomonori, Mike Frysinger, Graf Yang, Mikael Starvik,
Jesper Nilsson, Tony Luck, Fenghua Yu, Benjamin Herrenschmidt,
Paul Mackerras, Chen Liqin, Lennox Wu, Arnd Bergmann,
Thomas Gleixner, Ingo Molnar, H. Peter Anvin, x86,
Arjan van de Ven, Karsten Keil, Jesse Barnes, David S. Miller,
Alexey Kuznetsov, Pekka Savola (ipv6), James Morris,
Hideaki YOSHIFUJI, Patrick McHardy, Timo Teras, linux-alpha,
linux-kernel, uclinux-dist-devel, linux-cris-kernel, linux-ia64,
linuxppc-dev, netdev
Cc: vamos
Hi all!
First of all sorry for the huge CC, I couldn't come up with a way
to create a smaller list while reaching all the relevant people.
We, the vamos project[1] at the Friedrich Alexander University are
analything the linux configuration model trying to detect
errors. During a run with our tools we noticed the fact that the
option ALPHA_LEGACY_START_ADDRESS in arch/alpha/Kconfig.debug is
listed twice with contradictory dependencies on ALPHA_GENERIC.
Taking a closer look[2] we noticed 22 occurences where the same
config option is defined more than once in the same Kconfig file, not
all of them are, of course, contradictory as the ALPHA sample.
We"d be interested in reasons to keep this configuration split up
in the same file or if this is just a error introduced someeewhere in
linux' development that should be fixed.
Regards
Chritoph Egger
[ Please keep vamos@ Cc-ed -- we're not following all the lkml traffic
;) no need to keep me though ]
[1] http://vamos1.informatik.uni-erlangen.de
[2] grep ^config **/Kconfig* | sort | uniq -d -c
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox