On Wed, Feb 02, 2011 at 05:53:59PM -0600, Dave Kleikamp wrote:
> On Thu, 2011-02-03 at 10:08 +1100, David Gibson wrote:
> > On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
> > > Since other OS's may be running on the other cores don't use tlbivax
> >
> > [snip]
> > > +#ifdef CONFIG_
From: Ian Munsie
Many system calls are unimplemented and mapped to sys_ni_syscall, but at
boot ftrace would still search through every syscall metadata entry for
a match which wouldn't be there.
This patch adds causes the search to terminate early if the system call
is not mapped.
Signed-off-by
From: Ian Munsie
This patch implements the raw syscall tracepoints on PowerPC and exports
them for ftrace syscalls to use.
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.
From: Ian Munsie
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 moves the match logic
From: Ian Munsie
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
From: Ian Munsie
With the ftrace events now checking if the syscall_nr is valid upon
initialisation it should no longer be possible to register or unregister
a syscall event without a valid syscall_nr since they should not be
created. This adds a WARN_ON_ONCE in the register and unregister
functi
From: Ian Munsie
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 s
Hi All,
This is a partial version of my 'ftrace syscalls, PowerPC: Various fixes,
Compat Syscall support and PowerPC implementation'. This is updated from
yesterday with arch_syscall_addr changed to a static inline function from
Steven's suggestion.
This subset implements the raw syscall tracepoi
This property, defined in the Open PIC binding, tells the kernel not to use the
reset bit in the global configuration register. Additionally, its presence
mandates that only sources which are actually used (i.e. appear in the device
tree) should have their VECPRI bits initialized.
Signed-off-by:
This binding documents several properties that have been in use for quite
some time, and adds one new property 'no-reset', which controls whether the
Open PIC should be reset during runtime initialization.
The general formatting and interrupt specifier definition is based off of
Stuart Yoder's FSL
This patch set provides a binding for Open PIC and implements support for
a new property, specified by that binding, called 'no-reset'. With 'no-reset'
in place the 'protected-sources' property is no longer needed and was removed.
Signed-off-by: Meador Inge
CC: Hollis Blanchard
Meador Inge (3)
In a recent discussion [1, 2] concerning device trees for AMP systems, the
question of whether we really need 'protected-sources' arose. The general
consensus was that if you don't want a source to be used, then it should *not*
be mentioned in an 'interrupts' property. If a source really needs to
Excerpts from Steven Rostedt's message of Thu Feb 03 01:04:44 +1100 2011:
> I'll answer your question here.
> > +#define arch_syscall_match_sym_name(sym, name) !strcmp(sym + 3, name + 3)
>
> Instead, you could have:
>
> #ifndef ARCH_HAS_SYSCALL_MATCH_SYM_NAME
>
> static inline arch_syscall_matc
On Thu, 2011-02-03 at 10:06 +1100, David Gibson wrote:
> On Tue, Feb 01, 2011 at 12:48:41PM -0600, Dave Kleikamp wrote:
> > so that it can use information from the device tree.
>
> Hrm. On the other hand this means that the early_init_devtree() code
> can't benefit from hardcoded early debugging.
On Thu, 2011-02-03 at 10:08 +1100, David Gibson wrote:
> On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
> > Since other OS's may be running on the other cores don't use tlbivax
>
> [snip]
> > +#ifdef CONFIG_44x
> > +void __init early_init_mmu_44x(void)
> > +{
> > + unsigned long
On Tue, Feb 01, 2011 at 12:48:44PM -0600, Dave Kleikamp wrote:
> Since other OS's may be running on the other cores don't use tlbivax
[snip]
> +#ifdef CONFIG_44x
> +void __init early_init_mmu_44x(void)
> +{
> + unsigned long root = of_get_flat_dt_root();
> + if (of_flat_dt_is_compatible(ro
On Tue, Feb 01, 2011 at 12:48:41PM -0600, Dave Kleikamp wrote:
> so that it can use information from the device tree.
Hrm. On the other hand this means that the early_init_devtree() code
can't benefit from hardcoded early debugging. Since you don't
actually appear to use devtree information in u
On Wed, 2011-02-02 at 16:09 -0600, kevin diggs wrote:
> Hi,
>
> And one more thing: Why does an SMP kernel (mesh compiled in an SMP
> enabled kernel) work?
Could be an alignment or timing problem, depending on random things the
alignment of some DMA data structures or timing of access might end
Hi,
And one more thing: Why does an SMP kernel (mesh compiled in an SMP
enabled kernel) work?
What all does SMP do? If it matters, I'm voluntary preempt.
Is the DMA hardware in this thing used in any other system (I guess I
mean both other computers and other sub-systems in this computer -
does
So this is sort of a follow on question to one I posted a month ago about
trying to get a PCI driver to work with OF (which I think I more or less
understood the answer to). I'm encountering a different sort of problem
that I'd like to solve with OF but I'm not sure I can. Let me lay out a
li
Ben,
I know you are VERY busy. I appreciate your taking the time to reply.
Since I'm am still using this thing I'll take a stab at trying to
track it down. I just posted the FYI to see if I could trigger some
thoughts (like your post).
With a 4.3.5 compiled mesh, it fails a lot of early stuff li
On Wed, 2011-02-02 at 13:36 -0600, kevin diggs wrote:
> Hi,
>
> FYI:
>
> I have narrowed this down to drivers/scsi/mesh.c (the root disk
> controller for the PowerMac 8600). I have compiled everything else for
> 2.6.36 with 4.3.5, including modules. With a 4.1.2 compiled mesh.c the
> beast boots.
Hi,
FYI:
I have narrowed this down to drivers/scsi/mesh.c (the root disk
controller for the PowerMac 8600). I have compiled everything else for
2.6.36 with 4.3.5, including modules. With a 4.1.2 compiled mesh.c the
beast boots. I am using it to post this follow up.
kevin
> On Sat, Jan 22, 2011
Hi All,
I've added the following patches to my next branch:
Dave Kleikamp (2):
powerpc/476: define specific cpu table entry DD2 core
powerpc/476: Workaround for PLB6 hang
Rupjyoti Sarmah (1):
powerpc/44x: PHY fixup for USB on canyonlands board
Tirumala Marri (1):
powerpc
On Wed, 2011-02-02 at 14:15 +, David Laight wrote:
> > +#define arch_syscall_match_sym_name(sym, name) !strcmp(sym + 3, name
> + 3)
>
> Whenever you use a #define macro arg, you should enclose it in ().
> About the only time you don't need to is when it is being
> passed as an argument to anot
> +#define arch_syscall_match_sym_name(sym, name) !strcmp(sym + 3, name
+ 3)
Whenever you use a #define macro arg, you should enclose it in ().
About the only time you don't need to is when it is being
passed as an argument to another function
(ie when it's use is also ',' separated).
So the ab
On Wed, 2011-02-02 at 18:11 +1100, Ian Munsie wrote:
I'll answer your question here.
> diff --git a/include/linux/ftrace.h b/include/linux/ftrace.h
> index dcd6a7c..0d0e109 100644
> --- a/include/linux/ftrace.h
> +++ b/include/linux/ftrace.h
> @@ -527,6 +527,15 @@ extern enum ftrace_dump_mode ftr
On Wed, 2011-02-02 at 01:48 -0600, Kumar Gala wrote:
> On Feb 1, 2011, at 12:48 PM, Dave Kleikamp wrote:
>
> > Since other OS's may be running on the other cores don't use tlbivax
>
> Are you guys building SMP kernel for use with AMP? Just wondering why you'd
> be using tlbivax at all.
Yes, fo
On Tue, Feb 01, 2011 at 12:48:46PM -0600, Dave Kleikamp wrote:
> These are completely independent OS instances, each running on 2
> cores.
[snip]
> +/memreserve/ 0x01f0 0x0010;
A comment describing what this reserved section is for would be good.
> +/ {
> + #address-cells = <2>;
> +
29 matches
Mail list logo
