On Wed, 2010-05-12 at 23:13 -0500, pac...@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
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
From: Ian Munsie imun...@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
From: Ian Munsie imun...@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
From: Ian Munsie imun...@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
From: Ian Munsie imun...@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
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
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
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.
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
On Jan 25, 2010, at 11:25 AM, Kumar Gala wrote:
On Jan 25, 2010, at 11:06 AM, Aaron Pace wrote:
Is a simple hello world module sufficient to show the issue? I'll look
into it this week.
- k
It wasn't in my situation, unfortunately. To duplicate this, I had
one relatively large
On Jan 25, 2010, at 11:25 AM, Kumar Gala wrote:
On Jan 25, 2010, at 11:06 AM, Aaron Pace wrote:
Is a simple hello world module sufficient to show the issue? I'll look
into it this week.
- k
It wasn't in my situation, unfortunately. To duplicate this, I had
one relatively large
2010/5/13 Christian Kujau li...@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
On Thu, 2010-05-13 at 17:43 +1000, Ian Munsie wrote:
From: Ian Munsie imun...@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
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.
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 sebast...@breakpoint.cc
Cc: Maxim Uvarov muva...@gmail.com
Signed-off-by: Simon Horman ho...@verge.net.au
Index:
Frederic,
I'm fine with these patches, but since you mainly did the syscall work,
I'll let you take them.
The patches that touch the PowerPC code needs an acked-by from Ben or
Paul.
-- Steve
On Thu, 2010-05-13 at 17:43 +1000, Ian Munsie wrote:
This patch series implements raw system call
On Thu, May 13, 2010 at 12:06:11PM -0400, Steven Rostedt wrote:
Frederic,
I'm fine with these patches, but since you mainly did the syscall work,
I'll let you take them.
Sure.
The patches that touch the PowerPC code needs an acked-by from Ben or
Paul.
-- Steve
Ok,
Thanks.
Linker does not provide some vital functions when building
freestanding
applications with a new toolchain,
That's because the compiler provides those functions, not the linker.
so we have to provide our own CRT.
...in libgcc. Why don't you link against that?
p.s.
Without the CRT we
On Thu, May 13, 2010 at 07:27:59PM +0200, Segher Boessenkool wrote:
Linker does not provide some vital functions when building
freestanding
applications with a new toolchain,
That's because the compiler provides those functions, not the linker.
so we have to provide our own CRT.
...in
On May 7, 2010, at 3:38 AM, Li Yang wrote:
Check the user/supervisor execution permission base on the code address.
This fixes the following oops on module loading or removing.
Unable to handle kernel paging request for instruction fetch
Faulting instruction address: 0xf938d040
Oops:
On Thu, 2010-05-13 at 06:16 -0500, pac...@kosh.dhis.org wrote:
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
On Thu, 2010-05-13 at 14:14 -0500, Kumar Gala wrote:
On May 7, 2010, at 3:38 AM, Li Yang wrote:
Check the user/supervisor execution permission base on the code address.
This fixes the following oops on module loading or removing.
Unable to handle kernel paging request for instruction
On Thu, 2010-05-13 at 12:06 -0400, Steven Rostedt wrote:
Frederic,
I'm fine with these patches, but since you mainly did the syscall work,
I'll let you take them.
The patches that touch the PowerPC code needs an acked-by from Ben or
Paul.
Done :-)
Cheers,
Ben.
-- Steve
On Thu,
On Thu, 2010-05-13 at 17:43 +1000, Ian Munsie wrote:
From: Ian Munsie imun...@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
On Thu, 13 May 2010 at 15:50, Maxim Uvarov wrote:
zImage should not work with kexec. Only vmlinux.
should?
PPC64 has something nice there:
kexec/arch/ppc64/kexec-zImage-ppc64.c:
fprintf(stderr, zImage support is still broken\n);
but I could not figure out where this is called from.
I've updated the commit message to be a bit more clear on why
we need to do this.
I'm curious why the _PAGE_EXEC have different definition in pte-book3e.h
and pte-fsl-booke.h?
It is UX permission in pte-book3e, but is SX permission in
pte-fsl-booke.h.
Thanks, Dave
Excerpts from Michael Ellerman's message of Thu May 13 22:09:31 +1000 2010:
On Thu, 2010-05-13 at 17:43 +1000, Ian Munsie wrote:
From: Ian Munsie imun...@au.ibm.com
Hi Ian,
Just a few comments ..
This patch implements the raw syscall tracepoints on PowerPC required
for ftrace
Excerpts from Benjamin Herrenschmidt's message of Fri May 14 09:54:56 +1000
2010:
On Thu, 2010-05-13 at 17:43 +1000, Ian Munsie wrote:
From: Ian Munsie imun...@au1.ibm.com
Some architectures have unusual symbol names and the generic code to
match the symbol name with the function name
Not looking at the code right now ... but do we have the same
issue on 64e ?
Aaron pointed the issue on FSL BookE.
http://lists.ozlabs.org/pipermail/linuxppc-dev/2010-January/079738.html
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
add_dyn_reconf_usable_mem_property() iterates over memory spans
in /ibm,dynamic-reconfiguration-memory/ibm,dynamic-memory and intersects
these with usablemem_rgns ranges. In doing so it used an unchecked
fixed-size array which will overrun on machines with lots of LMBs.
This patch removes the
On Thu, 2010-05-13 at 14:14 -0500, Kumar Gala wrote:
On May 7, 2010, at 3:38 AM, Li Yang wrote:
Check the user/supervisor execution permission base on the code address.
This fixes the following oops on module loading or removing.
Unable to handle kernel paging request for instruction
On Fri, 2010-05-14 at 08:53 +0800, Liu Dave-R63238 wrote:
I've updated the commit message to be a bit more clear on why
we need to do this.
I'm curious why the _PAGE_EXEC have different definition in pte-book3e.h
and pte-fsl-booke.h?
It is UX permission in pte-book3e, but is SX
In kexec_prepare_cpus, the primary CPU IPIs the secondary CPUs to
kexec_smp_down(). kexec_smp_down() calls kexec_smp_wait() which sets
the hw_cpu_id() to -1. The primary does this while leaving IRQs on
which means the primary can take a timer interrupt which can lead to
the IPIing one of the
When we are crashing, the crashing/primary CPU IPIs the secondaries to
turn off IRQs, go into real mode and wait in kexec_wait. While this
is happening, the primary tears down all the MMU maps. Unfortunately
the primary doesn't check to make sure the secondaries have entered
real mode before
On May 13, 2010, at 10:36 PM, Benjamin Herrenschmidt wrote:
On Thu, 2010-05-13 at 14:14 -0500, Kumar Gala wrote:
On May 7, 2010, at 3:38 AM, Li Yang wrote:
Check the user/supervisor execution permission base on the code address.
This fixes the following oops on module loading or removing.
When we build with ftrace enabled its possible that loadcam_entry would
have used the stack pointer (even though the code doesn't need it). We
call loadcam_entry in __secondary_start before the stack is setup. To
ensure that loadcam_entry doesn't use the stack pointer the easiest
solution is to
The following changes since commit 131c6c9eddfa252e376edb4aeff9c7fe1b96a798:
Benjamin Herrenschmidt (1):
Merge commit 'kumar/merge' into merge
are available in the git repository at:
git://git.kernel.org/pub/scm/linux/kernel/git/galak/powerpc.git merge
Kumar Gala (1):
In kexec_prepare_cpus, the primary CPU IPIs the secondary CPUs to
kexec_smp_down(). kexec_smp_down() calls kexec_smp_wait() which sets
the hw_cpu_id() to -1. The primary does this while leaving IRQs on
which means the primary can take a timer interrupt which can lead to
the IPIing one of the
When we are crashing, the crashing/primary CPU IPIs the secondaries to
turn off IRQs, go into real mode and wait in kexec_wait. While this
is happening, the primary tears down all the MMU maps. Unfortunately
the primary doesn't check to make sure the secondaries have entered
real mode before
40 matches
Mail list logo
