* Re: [PATCH 2/2] powerpc - Make the irq reverse mapping radix tree lockless
From: Benjamin Herrenschmidt @ 2008-08-20 5:23 UTC (permalink / raw)
To: Sebastien Dugue
Cc: dwalker, tinytim, linux-rt-users, linux-kernel, rostedt,
jean-pierre.dion, linuxppc-dev, paulus, gilles.carry, tglx
In-Reply-To: <1218029429-21114-3-git-send-email-sebastien.dugue@bull.net>
BTW. It would be good to try to turn the GFP_ATOMIC into GFP_KERNEL,
maybe using a semaphore instead of a lock to protect insertion vs.
initialisation. The old scheme was fine because if the atomic allocation
failed, it could fallback to the linear search and try again on the next
interrupt. Not anymore.
Ben.
^ permalink raw reply
* Re: [PATCH 2/2] powerpc - Make the irq reverse mapping radix tree lockless
From: Benjamin Herrenschmidt @ 2008-08-20 5:22 UTC (permalink / raw)
To: Sebastien Dugue
Cc: dwalker, tinytim, linux-rt-users, linux-kernel, rostedt,
jean-pierre.dion, linuxppc-dev, paulus, gilles.carry, tglx
In-Reply-To: <1218029429-21114-3-git-send-email-sebastien.dugue@bull.net>
On Wed, 2008-08-06 at 15:30 +0200, Sebastien Dugue wrote:
> The radix trees used by interrupt controllers for their irq reverse mapping
> (currently only the XICS found on pSeries) have a complex locking scheme
> dating back to before the advent of the lockless radix tree.
>
> Take advantage of this and of the fact that the items of the tree are
> pointers to a static array (irq_map) elements which can never go under us
> to simplify the locking.
>
> Concurrency between readers and writers is handled by the intrinsic
> properties of the lockless radix tree. Concurrency between writers is handled
> with a spinlock added to the irq_host structure.
No need for a spinlock in the irq_host. Make it one global lock, it's
not like scalability of irq_create_mapping() was a big deal and there's
usually only one of those type of hosts anyway.
>
> Signed-off-by: Sebastien Dugue <sebastien.dugue@bull.net>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/include/asm/irq.h | 1 +
> arch/powerpc/kernel/irq.c | 74 ++++++----------------------------------
> 2 files changed, 12 insertions(+), 63 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
> index 0a51376..72fd036 100644
> --- a/arch/powerpc/include/asm/irq.h
> +++ b/arch/powerpc/include/asm/irq.h
> @@ -119,6 +119,7 @@ struct irq_host {
> } linear;
> struct radix_tree_root tree;
> } revmap_data;
> + spinlock_t tree_lock;
> struct irq_host_ops *ops;
> void *host_data;
> irq_hw_number_t inval_irq;
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index dc8663a..7a19103 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -439,8 +439,6 @@ void do_softirq(void)
>
> static LIST_HEAD(irq_hosts);
> static DEFINE_SPINLOCK(irq_big_lock);
> -static DEFINE_PER_CPU(unsigned int, irq_radix_reader);
> -static unsigned int irq_radix_writer;
> static atomic_t revmap_trees_allocated = ATOMIC_INIT(0);
> struct irq_map_entry irq_map[NR_IRQS];
> static unsigned int irq_virq_count = NR_IRQS;
> @@ -584,57 +582,6 @@ void irq_set_virq_count(unsigned int count)
> irq_virq_count = count;
> }
>
> -/* radix tree not lockless safe ! we use a brlock-type mecanism
> - * for now, until we can use a lockless radix tree
> - */
> -static void irq_radix_wrlock(unsigned long *flags)
> -{
> - unsigned int cpu, ok;
> -
> - spin_lock_irqsave(&irq_big_lock, *flags);
> - irq_radix_writer = 1;
> - smp_mb();
> - do {
> - barrier();
> - ok = 1;
> - for_each_possible_cpu(cpu) {
> - if (per_cpu(irq_radix_reader, cpu)) {
> - ok = 0;
> - break;
> - }
> - }
> - if (!ok)
> - cpu_relax();
> - } while(!ok);
> -}
> -
> -static void irq_radix_wrunlock(unsigned long flags)
> -{
> - smp_wmb();
> - irq_radix_writer = 0;
> - spin_unlock_irqrestore(&irq_big_lock, flags);
> -}
> -
> -static void irq_radix_rdlock(unsigned long *flags)
> -{
> - local_irq_save(*flags);
> - __get_cpu_var(irq_radix_reader) = 1;
> - smp_mb();
> - if (likely(irq_radix_writer == 0))
> - return;
> - __get_cpu_var(irq_radix_reader) = 0;
> - smp_wmb();
> - spin_lock(&irq_big_lock);
> - __get_cpu_var(irq_radix_reader) = 1;
> - spin_unlock(&irq_big_lock);
> -}
> -
> -static void irq_radix_rdunlock(unsigned long flags)
> -{
> - __get_cpu_var(irq_radix_reader) = 0;
> - local_irq_restore(flags);
> -}
> -
> static int irq_setup_virq(struct irq_host *host, unsigned int virq,
> irq_hw_number_t hwirq)
> {
> @@ -789,7 +736,6 @@ void irq_dispose_mapping(unsigned int virq)
> {
> struct irq_host *host;
> irq_hw_number_t hwirq;
> - unsigned long flags;
>
> if (virq == NO_IRQ)
> return;
> @@ -825,9 +771,9 @@ void irq_dispose_mapping(unsigned int virq)
> /* Check if radix tree allocated yet */
> if (atomic_read(&revmap_trees_allocated) == 0)
> break;
> - irq_radix_wrlock(&flags);
> + spin_lock(&host->tree_lock);
> radix_tree_delete(&host->revmap_data.tree, hwirq);
> - irq_radix_wrunlock(flags);
> + spin_unlock(&host->tree_lock);
> break;
> }
>
> @@ -881,7 +827,6 @@ unsigned int irq_radix_revmap_lookup(struct irq_host *host,
> {
> struct irq_map_entry *ptr;
> unsigned int virq = NO_IRQ;
> - unsigned long flags;
>
> WARN_ON(host->revmap_type != IRQ_HOST_MAP_TREE);
>
> @@ -893,9 +838,11 @@ unsigned int irq_radix_revmap_lookup(struct irq_host *host,
> return irq_find_mapping(host, hwirq);
>
> /* Now try to resolve */
> - irq_radix_rdlock(&flags);
> + /*
> + * No rcu_read_lock(ing) needed, the ptr returned can't go under us
> + * as it's referencing an entry in the static irq_map table.
> + */
> ptr = radix_tree_lookup(&host->revmap_data.tree, hwirq);
> - irq_radix_rdunlock(flags);
>
> /* Found it, return */
> if (ptr)
> @@ -907,7 +854,6 @@ unsigned int irq_radix_revmap_lookup(struct irq_host *host,
> void irq_radix_revmap_insert(struct irq_host *host, unsigned int virq,
> irq_hw_number_t hwirq)
> {
> - unsigned long flags;
>
> WARN_ON(host->revmap_type != IRQ_HOST_MAP_TREE);
>
> @@ -920,10 +866,10 @@ void irq_radix_revmap_insert(struct irq_host *host, unsigned int virq,
> return;
>
> if (virq != NO_IRQ) {
> - irq_radix_wrlock(&flags);
> + spin_lock(&host->tree_lock);
> radix_tree_insert(&host->revmap_data.tree, hwirq,
> &irq_map[virq]);
> - irq_radix_wrunlock(flags);
> + spin_unlock(&host->tree_lock);
> }
> }
>
> @@ -1041,8 +987,10 @@ static int irq_late_init(void)
> * revmap_trees_allocated.
> */
> list_for_each_entry(h, &irq_hosts, link) {
> - if (h->revmap_type == IRQ_HOST_MAP_TREE)
> + if (h->revmap_type == IRQ_HOST_MAP_TREE) {
> INIT_RADIX_TREE(&h->revmap_data.tree, GFP_ATOMIC);
> + spin_lock_init(&h->tree_lock);
> + }
> }
>
> /*
^ permalink raw reply
* Re: [PATCH 1/2] powerpc - Separate the irq radix tree insertion and lookup
From: Benjamin Herrenschmidt @ 2008-08-20 5:21 UTC (permalink / raw)
To: Sebastien Dugue
Cc: dwalker, tinytim, linux-rt-users, linux-kernel, rostedt,
jean-pierre.dion, linuxppc-dev, paulus, gilles.carry, tglx
In-Reply-To: <1218029429-21114-2-git-send-email-sebastien.dugue@bull.net>
On Wed, 2008-08-06 at 15:30 +0200, Sebastien Dugue wrote:
> irq_radix_revmap() currently serves 2 purposes, irq mapping lookup
> and insertion which happen in interrupt and process context respectively.
Sounds good, a few nits and it should be good to go.
> Separate the function into its 2 components, one for lookup only and one
> for insertion only.
>
> Fix the only user of the revmap tree (XICS) to use the new functions.
>
> Also, move the insertion into the radix tree of those irqs that were
> requested before it was initialized at said tree initialization.
>
> Mutual exclusion between the tree initialization and readers/writers is
> handled via an atomic variable (revmap_trees_allocated) set when the tree
> has been initialized and checked before any reader or writer access just
> like we used to check for tree.gfp_mask != 0 before.
The atomic doesn't need to be such. Could just be a global. In fact, I
don't like your synchronization too much between the init and _insert.
What I'd do is, turn your atomic into a simple int
- do smp_wmb() and set it to 1 after the tree is initialized, then
smb_wmb() again and set it to 2 after the tree has been filled
by the init code
- in the revmap_lookup path just test that it's >1, no need for a
barrier. At worst you'll use the slow path instead of the fast path some
time during boot, no big deal.
- in the insert path, do an smp_rb() and if it's >0 do the insert with
the lock
- in the init pre-insert path, use the lock inside the loop for each
insertion.
that means you may get concurrent attempt to insert but the lock will
help there and turn them into 2 insertions of the same translation. Is
that a big deal ? If it is, make it be a lookup+insert.
Ben.
>
> Signed-off-by: Sebastien Dugue <sebastien.dugue@bull.net>
> Cc: Paul Mackerras <paulus@samba.org>
> Cc: Benjamin Herrenschmidt <benh@kernel.crashing.org>
> Cc: Michael Ellerman <michael@ellerman.id.au>
> ---
> arch/powerpc/include/asm/irq.h | 18 ++++++-
> arch/powerpc/kernel/irq.c | 76 ++++++++++++++++++++++++---------
> arch/powerpc/platforms/pseries/xics.c | 11 ++---
> 3 files changed, 74 insertions(+), 31 deletions(-)
>
> diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
> index a372f76..0a51376 100644
> --- a/arch/powerpc/include/asm/irq.h
> +++ b/arch/powerpc/include/asm/irq.h
> @@ -236,15 +236,27 @@ extern unsigned int irq_find_mapping(struct irq_host *host,
> extern unsigned int irq_create_direct_mapping(struct irq_host *host);
>
> /**
> - * irq_radix_revmap - Find a linux virq from a hw irq number.
> + * irq_radix_revmap_insert - Insert a hw irq to linux virq number mapping.
> + * @host: host owning this hardware interrupt
> + * @virq: linux irq number
> + * @hwirq: hardware irq number in that host space
> + *
> + * This is for use by irq controllers that use a radix tree reverse
> + * mapping for fast lookup.
> + */
> +extern void irq_radix_revmap_insert(struct irq_host *host, unsigned int virq,
> + irq_hw_number_t hwirq);
> +
> +/**
> + * irq_radix_revmap_lookup - Find a linux virq from a hw irq number.
> * @host: host owning this hardware interrupt
> * @hwirq: hardware irq number in that host space
> *
> * This is a fast path, for use by irq controller code that uses radix tree
> * revmaps
> */
> -extern unsigned int irq_radix_revmap(struct irq_host *host,
> - irq_hw_number_t hwirq);
> +extern unsigned int irq_radix_revmap_lookup(struct irq_host *host,
> + irq_hw_number_t hwirq);
>
> /**
> * irq_linear_revmap - Find a linux virq from a hw irq number.
> diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
> index d972dec..dc8663a 100644
> --- a/arch/powerpc/kernel/irq.c
> +++ b/arch/powerpc/kernel/irq.c
> @@ -441,6 +441,7 @@ static LIST_HEAD(irq_hosts);
> static DEFINE_SPINLOCK(irq_big_lock);
> static DEFINE_PER_CPU(unsigned int, irq_radix_reader);
> static unsigned int irq_radix_writer;
> +static atomic_t revmap_trees_allocated = ATOMIC_INIT(0);
> struct irq_map_entry irq_map[NR_IRQS];
> static unsigned int irq_virq_count = NR_IRQS;
> static struct irq_host *irq_default_host;
> @@ -822,7 +823,7 @@ void irq_dispose_mapping(unsigned int virq)
> break;
> case IRQ_HOST_MAP_TREE:
> /* Check if radix tree allocated yet */
> - if (host->revmap_data.tree.gfp_mask == 0)
> + if (atomic_read(&revmap_trees_allocated) == 0)
> break;
> irq_radix_wrlock(&flags);
> radix_tree_delete(&host->revmap_data.tree, hwirq);
> @@ -875,43 +876,55 @@ unsigned int irq_find_mapping(struct irq_host *host,
> EXPORT_SYMBOL_GPL(irq_find_mapping);
>
>
> -unsigned int irq_radix_revmap(struct irq_host *host,
> - irq_hw_number_t hwirq)
> +unsigned int irq_radix_revmap_lookup(struct irq_host *host,
> + irq_hw_number_t hwirq)
> {
> - struct radix_tree_root *tree;
> struct irq_map_entry *ptr;
> - unsigned int virq;
> + unsigned int virq = NO_IRQ;
> unsigned long flags;
>
> WARN_ON(host->revmap_type != IRQ_HOST_MAP_TREE);
>
> - /* Check if the radix tree exist yet. We test the value of
> - * the gfp_mask for that. Sneaky but saves another int in the
> - * structure. If not, we fallback to slow mode
> + /*
> + * Check if the radix tree exist yet.
> + * If not, we fallback to slow mode
> */
> - tree = &host->revmap_data.tree;
> - if (tree->gfp_mask == 0)
> + if (atomic_read(&revmap_trees_allocated) == 0)
> return irq_find_mapping(host, hwirq);
>
> /* Now try to resolve */
> irq_radix_rdlock(&flags);
> - ptr = radix_tree_lookup(tree, hwirq);
> + ptr = radix_tree_lookup(&host->revmap_data.tree, hwirq);
> irq_radix_rdunlock(flags);
>
> /* Found it, return */
> - if (ptr) {
> + if (ptr)
> virq = ptr - irq_map;
> - return virq;
> - }
>
> - /* If not there, try to insert it */
> - virq = irq_find_mapping(host, hwirq);
> + return virq;
> +}
> +
> +void irq_radix_revmap_insert(struct irq_host *host, unsigned int virq,
> + irq_hw_number_t hwirq)
> +{
> + unsigned long flags;
> +
> + WARN_ON(host->revmap_type != IRQ_HOST_MAP_TREE);
> +
> + /*
> + * Check if the radix tree exist yet.
> + * If not, then the irq will be inserted into the tree when it gets
> + * initialized.
> + */
> + if (atomic_read(&revmap_trees_allocated) == 0)
> + return;
> +
> if (virq != NO_IRQ) {
> irq_radix_wrlock(&flags);
> - radix_tree_insert(tree, hwirq, &irq_map[virq]);
> + radix_tree_insert(&host->revmap_data.tree, hwirq,
> + &irq_map[virq]);
> irq_radix_wrunlock(flags);
> }
> - return virq;
> }
>
> unsigned int irq_linear_revmap(struct irq_host *host,
> @@ -1020,14 +1033,35 @@ void irq_early_init(void)
> static int irq_late_init(void)
> {
> struct irq_host *h;
> - unsigned long flags;
> + unsigned int i;
>
> - irq_radix_wrlock(&flags);
> + /*
> + * No mutual exclusion with respect to accessors of the tree is needed
> + * here as the synchronization is done via the atomic variable
> + * revmap_trees_allocated.
> + */
> list_for_each_entry(h, &irq_hosts, link) {
> if (h->revmap_type == IRQ_HOST_MAP_TREE)
> INIT_RADIX_TREE(&h->revmap_data.tree, GFP_ATOMIC);
> }
> - irq_radix_wrunlock(flags);
> +
> + /*
> + * Insert the reverse mapping for those interrupts already present
> + * in irq_map[].
> + */
> + for (i = 0; i < irq_virq_count; i++) {
> + if (irq_map[i].host &&
> + (irq_map[i].host->revmap_type == IRQ_HOST_MAP_TREE))
> + radix_tree_insert(&irq_map[i].host->revmap_data.tree,
> + irq_map[i].hwirq, &irq_map[i]);
> + }
> +
> + /*
> + * Make sure the radix trees inits are visible before setting
> + * the flag
> + */
> + smp_mb();
> + atomic_set(&revmap_trees_allocated, 1);
>
> return 0;
> }
> diff --git a/arch/powerpc/platforms/pseries/xics.c b/arch/powerpc/platforms/pseries/xics.c
> index 0fc830f..6b1a005 100644
> --- a/arch/powerpc/platforms/pseries/xics.c
> +++ b/arch/powerpc/platforms/pseries/xics.c
> @@ -310,12 +310,6 @@ static void xics_mask_irq(unsigned int virq)
>
> static unsigned int xics_startup(unsigned int virq)
> {
> - unsigned int irq;
> -
> - /* force a reverse mapping of the interrupt so it gets in the cache */
> - irq = (unsigned int)irq_map[virq].hwirq;
> - irq_radix_revmap(xics_host, irq);
> -
> /* unmask it */
> xics_unmask_irq(virq);
> return 0;
> @@ -346,7 +340,7 @@ static inline unsigned int xics_remap_irq(unsigned int vec)
>
> if (vec == XICS_IRQ_SPURIOUS)
> return NO_IRQ;
> - irq = irq_radix_revmap(xics_host, vec);
> + irq = irq_radix_revmap_lookup(xics_host, vec);
> if (likely(irq != NO_IRQ))
> return irq;
>
> @@ -530,6 +524,9 @@ static int xics_host_map(struct irq_host *h, unsigned int virq,
> {
> pr_debug("xics: map virq %d, hwirq 0x%lx\n", virq, hw);
>
> + /* Insert the interrupt mapping into the radix tree for fast lookup */
> + irq_radix_revmap_insert(xics_host, virq, hw);
> +
> get_irq_desc(virq)->status |= IRQ_LEVEL;
> set_irq_chip_and_handler(virq, xics_irq_chip, handle_fasteoi_irq);
> return 0;
^ permalink raw reply
* Re: [PATCH 4/8] powerpc: add the ability for a classic ppc kernel to be loaded at 32M
From: Paul Mackerras @ 2008-08-20 4:57 UTC (permalink / raw)
To: avorontsov; +Cc: Scott Wood, linuxppc-dev
In-Reply-To: <20080801203819.GA27753@polina.dev.rtsoft.ru>
Anton Vorontsov writes:
> > What do you do about the exception vectors?
>
> Making a trampoline code in place of exception vectors. See this patch:
>
> [PATCH 8/8] powerpc: last bits to support kdump on ppc32
It would probably be worth looking at whether we could do a
relocatable 32-bit kernel by linking it as a PIE and processing the
dynamic relocations at boot time (like the patches I posted recently
for 64-bit).
Paul.
^ permalink raw reply
* Re: CONFIG_BOOTX_TEXT breaks PowerBook 3400 with BootX
From: Benjamin Herrenschmidt @ 2008-08-20 4:07 UTC (permalink / raw)
To: Finn Thain; +Cc: linuxppc-dev
In-Reply-To: <Pine.LNX.4.64.0808200148080.24338@loopy.telegraphics.com.au>
On Wed, 2008-08-20 at 03:23 +1000, Finn Thain wrote:
> Hi All,
>
> When I build kernels with CONFIG_BOOTX_TEXT enabled I can't boot a PB 3400
> with BootX. I get a black screen with "Welcome to Linux" at the top, then
> it appears to hang. Debian kernels are configured this way and suffer the
> same problem.
>
> I don't know if Quik is affected. It is a bit of a hassle at install time
> since the (mediabay) floppy drive can't co-exist with the (mediabay)
> CDROM, so I'm using BootX to do the Debian install.
>
> The Debian Sarge 2.6.8-4 kernel does not seem to have this problem though
> kernel.org 2.6.16 and later versions do.
>
> Any ideas?
How "late" have you tried ? I remember fixing something at one point...
Ben.
^ permalink raw reply
* [git pull] Please pull powerpc.git merge branch
From: Paul Mackerras @ 2008-08-20 3:50 UTC (permalink / raw)
To: Linus Torvalds; +Cc: linuxppc-dev, akpm, linux-kernel
Linus,
Please pull from the 'merge' branch of
git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git merge
to get some more bug-fixes for powerpc.
Paul.
arch/powerpc/kernel/crash_dump.c | 31 +++++++++++++++++++++=
--------
arch/powerpc/kernel/ibmebus.c | 12 -----------
arch/powerpc/kernel/vio.c | 2 +-
arch/powerpc/platforms/cell/spufs/run.c | 15 +++++++-------
arch/powerpc/platforms/cell/spufs/sched.c | 11 ++++++++--
drivers/of/device.c | 10 +++++++++
6 files changed, 50 insertions(+), 31 deletions(-)
Brian King (1):
powerpc: Fix vio_bus_probe oops on probe error
Ilpo J=E4rvinen (1):
powerpc/spufs: Remove invalid semicolon after if statement
Jeremy Kerr (2):
powerpc/spufs: fix npc setting for NOSCHED contexts
powerpc/spufs: reference context while dropping state mutex in sc=
heduler
Joachim Fenkes (1):
powerpc/ibmebus: Restore "name" sysfs attribute on ibmebus device=
s
Michael Ellerman (1):
powerpc: Fix /dev/oldmem interface for kdump
^ permalink raw reply
* Re: [PATCH 3/4] kvmppc: magic page paravirtualization - guest part
From: Tony Breeds @ 2008-08-20 2:29 UTC (permalink / raw)
To: ehrhardt; +Cc: linuxppc-dev, hollisb, kvm-ppc
In-Reply-To: <1219142204-12044-4-git-send-email-ehrhardt@linux.vnet.ibm.com>
Hi Christian,
One very minor nit.
On Tue, Aug 19, 2008 at 12:36:43PM +0200, ehrhardt@linux.vnet.ibm.com wrote:
> [diffstat]
> mm/page_alloc.c | 1
<snip>
> void kvm_guest_init(void);
> diff --git a/mm/page_alloc.c b/mm/page_alloc.c
> --- a/mm/page_alloc.c
> +++ b/mm/page_alloc.c
> @@ -550,6 +550,7 @@
> prefetchw(p + 1);
> __ClearPageReserved(p);
> set_page_count(p, 0);
> +
> }
>
> set_page_refcounted(page);
I guess this is a leftover from some debugging but still should be
killed :)
Yours Tony
linux.conf.au http://www.marchsouth.org/
Jan 19 - 24 2009 The Australian Linux Technical Conference!
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Benjamin Herrenschmidt @ 2008-08-20 1:17 UTC (permalink / raw)
To: Jeremy Fitzhardinge
Cc: Nick Piggin, Paul E. McKenney, Mathieu Desnoyers, linux-kernel,
Steven Rostedt, linuxppc-dev, Steven Rostedt, Scott Wood,
Eran Liberty
In-Reply-To: <48AB5E36.8030400@goop.org>
On Tue, 2008-08-19 at 16:58 -0700, Jeremy Fitzhardinge wrote:
> Benjamin Herrenschmidt wrote:
> >> Ok, there are two cases where it's ok :
> >>
> >> 1 - in stop_machine, considering we are not touching code executed in
> >> NMI handlers.
> >> 2 - when using my replace_instruction_safe() which uses a temporary
> >> breakpoint when doing the instruction replacement.
> >>
> >> In those cases you could use text_poke_early().
> >>
> >
> > Note that vmap/vunmap will be very slow.
> >
>
> Don't we have Nick's speedups now?
Not sure what speedups this is, but it's stlil not something you want to
do a lot ... setting up and tearing down MMU mappings isn't something
I'd like to see happening on a per-mcount basis.
Ben
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Jeremy Fitzhardinge @ 2008-08-19 23:58 UTC (permalink / raw)
To: benh
Cc: Nick Piggin, Paul E. McKenney, Mathieu Desnoyers, linux-kernel,
Steven Rostedt, linuxppc-dev, Steven Rostedt, Scott Wood,
Eran Liberty
In-Reply-To: <1219182471.7826.16.camel@pasglop>
Benjamin Herrenschmidt wrote:
>> Ok, there are two cases where it's ok :
>>
>> 1 - in stop_machine, considering we are not touching code executed in
>> NMI handlers.
>> 2 - when using my replace_instruction_safe() which uses a temporary
>> breakpoint when doing the instruction replacement.
>>
>> In those cases you could use text_poke_early().
>>
>
> Note that vmap/vunmap will be very slow.
>
Don't we have Nick's speedups now?
J
^ permalink raw reply
* Re: [PATCH] ibmebus/of_platform: Move "name" sysfs attribute into generic OF devices
From: Paul Mackerras @ 2008-08-19 23:29 UTC (permalink / raw)
To: Joachim Fenkes
Cc: Stephen Rothwell, Olaf Hering, Paul Mackerras, LKML, LinuxPPC-Dev,
Christoph Raisch, Hoang-Nam Nguyen, Alexander Schmidt1,
Stefan Roscher, David S. Miller
In-Reply-To: <OFD6515867.CFE29C04-ONC12574AA.003B8D55-C12574AA.003BB443@de.ibm.com>
Joachim Fenkes writes:
> > Is this a bugfix that is needed for 2.6.27?
>
> Yes, definitely. The eHCA userspace driver relies on the name attribute to
> check for valid adapters (it checks that the name is "lhca"), so with the
> name attribute gone, eHCA userspace will cease to work.
OK, I'll put it in. Please, in future, always say explicitly if you
think a patch needs to go in to the kernel we're currently
stablizing. Otherwise, I'll generally assume it's for the next merge
window.
Paul.
^ permalink raw reply
* Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling
From: Alan Cox @ 2008-08-19 22:04 UTC (permalink / raw)
To: Jon Smirl
Cc: Alessandro Zummo, rtc-linux, linux-kernel, linuxppc-dev,
Andrew Morton
In-Reply-To: <9e4733910808191423u34946955lc85caa6b2217b390@mail.gmail.com>
> I don't know the status of these platforms....
>
> asm-blackfin/irq.h:#define NO_IRQ ((unsigned int)(-1))
> asm-mn10300/irq.h:#define NO_IRQ INT_MAX
> asm-parisc/irq.h:#define NO_IRQ (-1)
In need of fixing, assuming they actually use NO_IRQ for anything - don't
be mislead by the fact they may have old defines lying around.
Alan
^ permalink raw reply
* Re: [PATCH] Linux Device Driver for Xilinx LL TEMAC 10/100/1000 EthernetNIC
From: David H. Lynch Jr. @ 2008-08-19 22:12 UTC (permalink / raw)
To: John Linn; +Cc: Ben Hutchings, netdev, Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <20080819214207.084C115A8055@mail165-dub.bigfish.com>
John Linn wrote:
>
> What about you getting all the review & testing done and then we
> (Xilinx) will add the OF support to the driver?
>
> I doubt the powerpc mainline will take the driver without OF support. In
> fact, we had to remove the platform bus support from the last driver
> that we put into mainline for arch/powerpc.
>
That is perfectly fine with me. i will try to pull the xilinx git tree
and see how much closer I can make the probe so that converting will be
easier.
>
>
> xilinx_lltemac is the preferred.
>
> I don't think using xilinx_lltemac should cause problems. Our Xilinx
> Git tree has a xilinx_lltemac subdir that contains the non-flat driver
> but that should be ok with your xilinx_lltemac.c file in the net
> directory.
>
The next patch incarnation will have everything as xilinx_lltemac -
including the file as xilinx_lltemac.c
--
Dave Lynch DLA Systems
Software Development: Embedded Linux
717.627.3770 dhlii@dlasys.net http://www.dlasys.net
fax: 1.253.369.9244 Cell: 1.717.587.7774
Over 25 years' experience in platforms, languages, and technologies too numerous to list.
"Any intelligent fool can make things bigger and more complex... It takes a touch of genius - and a lot of courage to move in the opposite direction."
Albert Einstein
^ permalink raw reply
* DMA Cache problem on PPC8248.
From: Jayasri Sangu @ 2008-08-19 21:53 UTC (permalink / raw)
To: 'linuxppc-dev@ozlabs.org'
[-- Attachment #1: Type: text/plain, Size: 419 bytes --]
Hi All,
We are using PPC8248 provided by freescale and the kernel 2.6.10. I believe we have cache problem.
We are allocating DMA buffers in our driver. If we increase the DMA buffer size the board hangs/halts(when try to load more applications).
If we reduce the DMA buffer size, then we can run all our applications.
Is there any way I can get around this problem.
Thanks
Jayasri
[-- Attachment #2: Type: text/html, Size: 1080 bytes --]
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Benjamin Herrenschmidt @ 2008-08-19 21:47 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Paul E. McKenney, linux-kernel, Steven Rostedt, linuxppc-dev,
Steven Rostedt, Scott Wood, Eran Liberty
In-Reply-To: <20080819173453.GA28239@Krystal>
>
> Ok, there are two cases where it's ok :
>
> 1 - in stop_machine, considering we are not touching code executed in
> NMI handlers.
> 2 - when using my replace_instruction_safe() which uses a temporary
> breakpoint when doing the instruction replacement.
>
> In those cases you could use text_poke_early().
Note that vmap/vunmap will be very slow.
Ben.
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Benjamin Herrenschmidt @ 2008-08-19 21:46 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Eran Liberty, linux-kernel, rostedt, linuxppc-dev, Steven Rostedt,
Paul E. McKenney
In-Reply-To: <20080819130216.GA18001@Krystal>
> Register GPR30 is always zero... (also true for the other oops)
>From my experiments, -a- non volatile register gets corrupted. Not
always the same and not always with the same value.
The corruption -seems- to happen due to corruption of the location on
the stack where it was saved to / restored from in a previous function
call or interrupt.
I haven't yet tracked down what actually whacks the stack.
Ben.
^ permalink raw reply
* RE: [PATCH] Linux Device Driver for Xilinx LL TEMAC 10/100/1000 EthernetNIC
From: John Linn @ 2008-08-19 21:42 UTC (permalink / raw)
To: David H. Lynch Jr.
Cc: Ben Hutchings, netdev, Stephen Neuendorffer, linuxppc-embedded
In-Reply-To: <48AB38AF.6010007@dlasys.net>
I screwed up and forgot to copy all on this previously.
> -----Original Message-----
> From: David H. Lynch Jr. [mailto:dhlii@dlasys.net]
> Sent: Tuesday, August 19, 2008 3:19 PM
> To: John Linn
> Subject: Re: [PATCH] Linux Device Driver for Xilinx LL TEMAC
10/100/1000 EthernetNIC
> =
> John Linn wrote:
> >> Stephen wants OF support -which is fine, but I can not test
that.
> >>
> >
> > I definitely agree with Stephen that OF support is needed since
arch/ppc
> > has gone away. We aren't doing any new work on arch/ppc.
> >
> > Are you not planning to move to arch/powerpc anytime soon? I could
help
> > you with that transition which would be better in the long run. I'd
> > rather do that than do testing for you as I think it would be more
> > productive, but I've been wrong before.
> >
> =
> We will move to powerpc, but not in the time-frame I am hoping for
this
> driver.
> In the context of Linux and Pico, "we" means me, and there is no time
to
> do the work anytime soon.
> =
<snip>
What about you getting all the review & testing done and then we
(Xilinx) will add the OF support to the driver? =
I doubt the powerpc mainline will take the driver without OF support. In
fact, we had to remove the platform bus support from the last driver
that we put into mainline for arch/powerpc.
> =
> >> I would like
> >> one and only one tag that can be used end-end.
> >>
> >> Is there something xilinx will object to ? Prefer ? ....
> >>
> >>
> > xilinx_<device name>, (xilinx_lltemac or xilinx_ps2) is what we use
for
> > file names. The device tree does use "xlnx" to identify xilinx
devices,
> > but I don't think that should dictate file names.
> >
> > We have a driver in out GIT tree that is not flat (as most know) for
the
> > LL TEMAC and we are working on creating flat drivers for future
devices.
> > Ideally this new driver would be a replacement for our driver.
> >
> =
> Give me a name and I will go with it. the xps_lltemac name came from
> Yoshio,
> It is not in stone.
> =
> If I name the module "xilinx_lltemac" and go with xilinx_lltemac.c for
> the file name,
> is that going to cause problems with xilinx ?
> =
> I will use whatever you recomend.
xilinx_lltemac is the preferred. =
I don't think using xilinx_lltemac should cause problems. Our Xilinx
Git tree has a xilinx_lltemac subdir that contains the non-flat driver
but that should be ok with your xilinx_lltemac.c file in the net
directory.
> =
> --
> Dave Lynch DLA Systems
> Software Development:
Embedded Linux
> 717.627.3770 dhlii@dlasys.net http://www.dlasys.net
> fax: 1.253.369.9244 Cell: 1.717.587.7774
> Over 25 years' experience in platforms, languages, and technologies
too numerous to list.
> =
> "Any intelligent fool can make things bigger and more complex... It
takes a touch of genius - and a
> lot of courage to move in the opposite direction."
> Albert Einstein
> =
This email and any attachments are intended for the sole use of the named r=
ecipient(s) and contain(s) confidential information that may be proprietary=
, privileged or copyrighted under applicable law. If you are not the intend=
ed recipient, do not read, copy, or forward this email message or any attac=
hments. Delete this email message and any attachments immediately.
^ permalink raw reply
* Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling
From: Jon Smirl @ 2008-08-19 21:23 UTC (permalink / raw)
To: Alan Cox
Cc: Alessandro Zummo, rtc-linux, linux-kernel, linuxppc-dev,
Andrew Morton
In-Reply-To: <20080819212937.01dfd024@lxorguk.ukuu.org.uk>
On 8/19/08, Alan Cox <alan@lxorguk.ukuu.org.uk> wrote:
> > Shouldn't this be
> >
> > > - if (client->irq <= NO_IRQ)
> >
> > instead of
>
>
> NO_IRQ is obsolete. client->irq != is the test and IRQ numbers are
> unsigned.
I don't know the status of these platforms....
asm-blackfin/irq.h:#define NO_IRQ ((unsigned int)(-1))
asm-mn10300/irq.h:#define NO_IRQ INT_MAX
asm-parisc/irq.h:#define NO_IRQ (-1)
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling
From: Anton Vorontsov @ 2008-08-19 21:12 UTC (permalink / raw)
To: Jon Smirl
Cc: Alessandro Zummo, Andrew Morton, linux-kernel, rtc-linux,
linuxppc-dev
In-Reply-To: <9e4733910808191339s28a05f90pef57961e8d24fbdb@mail.gmail.com>
On Tue, Aug 19, 2008 at 04:39:09PM -0400, Jon Smirl wrote:
> On 8/12/08, Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> > On a PowerPC board with ds1374 RTC I'm getting this error while
> > RTC tries to probe:
> >
> > rtc-ds1374 0-0068: unable to request IRQ
> >
> > This happens because I2C probing code (drivers/of/of_i2c.c) is
> > specifying IRQ0 for 'no irq' case, which is correct.
>
> Shouldn't this be
>
> > - if (client->irq <= NO_IRQ)
>
> instead of
>
> > - if (client->irq < 0)
> > + if (client->irq <= 0)
>
> Since NO_IRQ can vary by platform (0 or -1)?
First of all, NO_IRQ is not defined for every architecture. You can't
use it for truly cross-platform drivers.
Secondly, "<= 0" will work for both NO_IRQ == 0 and NO_IRQ == -1,
since client->irq is signed type.
As for false positives, I don't believe that there is any platform
that use IRQ0 for external interrupts.
[...]
> In of_i2c.c shouldn't there be an error check?
>
> info.irq = irq_of_parse_and_map(node, 0);
>
> if (info.irq < NO_IRQ) {report error; continue }
irq_of_parse_and_map() returns unsigned type, plus it is defined
only for PowerPC, and for PowerPC NO_IRQ is always 0.
--
Anton Vorontsov
email: cbouatmailru@gmail.com
irc://irc.freenode.net/bd2
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Steven Rostedt @ 2008-08-19 21:08 UTC (permalink / raw)
To: Mathieu Desnoyers
Cc: Paul E. McKenney, linux-kernel, linuxppc-dev, Steven Rostedt,
Scott Wood, Eran Liberty
In-Reply-To: <20080819173453.GA28239@Krystal>
On Tue, 19 Aug 2008, Mathieu Desnoyers wrote:
>
> Ok, there are two cases where it's ok :
>
> 1 - in stop_machine, considering we are not touching code executed in
> NMI handlers.
> 2 - when using my replace_instruction_safe() which uses a temporary
> breakpoint when doing the instruction replacement.
>
> In those cases you could use text_poke_early().
>
> See
> http://git.kernel.org/?p=linux/kernel/git/compudj/linux-2.6-lttng.git;a=blob;f=arch/x86/kernel/immediate.c;h=7789e2c75bf03e645f15759d5dff0c1698493f92;hb=HEAD
>
> For a use example. Basically it looks like :
>
>
> 360 pages[0] = virt_to_page((void *)bypass_eip);
> 361 vaddr = vmap(pages, 1, VM_MAP, PAGE_KERNEL);
> 362 BUG_ON(!vaddr);
> 363 text_poke_early(&vaddr[bypass_eip & ~PAGE_MASK],
> 364 (void *)addr, size);
> 365 /*
> 366 * Fill the rest with nops.
> 367 */
> 368 len = NR_NOPS - size;
> 369 add_nops((void *)
> 370 &vaddr[(bypass_eip & ~PAGE_MASK) + size],
> 371 len);
> 372 print_dbg_bytes("inserted nops",
> 373 &vaddr[(bypass_eip & ~PAGE_MASK) + size], len);
> 374 vunmap(vaddr);
vunmap can not be called with interrupts disabled, and this is exactly
what my code does.
-- Steve
^ permalink raw reply
* Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling
From: Alan Cox @ 2008-08-19 20:29 UTC (permalink / raw)
To: Jon Smirl
Cc: Alessandro Zummo, rtc-linux, linux-kernel, linuxppc-dev,
Andrew Morton
In-Reply-To: <9e4733910808191339s28a05f90pef57961e8d24fbdb@mail.gmail.com>
> Shouldn't this be
>
> > - if (client->irq <= NO_IRQ)
>
> instead of
NO_IRQ is obsolete. client->irq != is the test and IRQ numbers are
unsigned.
Alan
^ permalink raw reply
* Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling
From: Jon Smirl @ 2008-08-19 20:39 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Alessandro Zummo, Andrew Morton, linux-kernel, rtc-linux,
linuxppc-dev
In-Reply-To: <20080812161733.GA32164@oksana.dev.rtsoft.ru>
On 8/12/08, Anton Vorontsov <avorontsov@ru.mvista.com> wrote:
> On a PowerPC board with ds1374 RTC I'm getting this error while
> RTC tries to probe:
>
> rtc-ds1374 0-0068: unable to request IRQ
>
> This happens because I2C probing code (drivers/of/of_i2c.c) is
> specifying IRQ0 for 'no irq' case, which is correct.
Shouldn't this be
> - if (client->irq <= NO_IRQ)
instead of
> - if (client->irq < 0)
> + if (client->irq <= 0)
Since NO_IRQ can vary by platform (0 or -1)? Work is underway to get
everyone onto NO_IRQ=0 but I don't know if it is finished yet. It is
much cleaner to use the NO_IRQ define.
In of_i2c.c shouldn't there be an error check?
info.irq = irq_of_parse_and_map(node, 0);
if (info.irq < NO_IRQ) {report error; continue }
>
> The driver handles this incorrectly, though. This patch fixes it.
>
> Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
> ---
> drivers/rtc/rtc-ds1374.c | 10 +++++-----
> 1 files changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/drivers/rtc/rtc-ds1374.c b/drivers/rtc/rtc-ds1374.c
> index 640acd2..a150418 100644
> --- a/drivers/rtc/rtc-ds1374.c
> +++ b/drivers/rtc/rtc-ds1374.c
> @@ -173,7 +173,7 @@ static int ds1374_read_alarm(struct device *dev, struct rtc_wkalrm *alarm)
> int cr, sr;
> int ret = 0;
>
> - if (client->irq < 0)
> + if (client->irq <= 0)
> return -EINVAL;
>
> mutex_lock(&ds1374->mutex);
> @@ -212,7 +212,7 @@ static int ds1374_set_alarm(struct device *dev, struct rtc_wkalrm *alarm)
> int cr;
> int ret = 0;
>
> - if (client->irq < 0)
> + if (client->irq <= 0)
> return -EINVAL;
>
> ret = ds1374_read_time(dev, &now);
> @@ -381,7 +381,7 @@ static int ds1374_probe(struct i2c_client *client,
> if (ret)
> goto out_free;
>
> - if (client->irq >= 0) {
> + if (client->irq > 0) {
> ret = request_irq(client->irq, ds1374_irq, 0,
> "ds1374", client);
> if (ret) {
> @@ -401,7 +401,7 @@ static int ds1374_probe(struct i2c_client *client,
> return 0;
>
> out_irq:
> - if (client->irq >= 0)
> + if (client->irq > 0)
> free_irq(client->irq, client);
>
> out_free:
> @@ -414,7 +414,7 @@ static int __devexit ds1374_remove(struct i2c_client *client)
> {
> struct ds1374 *ds1374 = i2c_get_clientdata(client);
>
> - if (client->irq >= 0) {
> + if (client->irq > 0) {
> mutex_lock(&ds1374->mutex);
> ds1374->exiting = 1;
> mutex_unlock(&ds1374->mutex);
>
> --
> 1.5.6.3
>
> _______________________________________________
> Linuxppc-dev mailing list
> Linuxppc-dev@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-dev
>
--
Jon Smirl
jonsmirl@gmail.com
^ permalink raw reply
* Re: ftrace introduces instability into kernel 2.6.27(-rc2,-rc3)
From: Steven Rostedt @ 2008-08-19 20:15 UTC (permalink / raw)
To: Eran Liberty
Cc: linuxppc-dev, Steven Rostedt, Paul E. McKenney, Mathieu Desnoyers,
linux-kernel
In-Reply-To: <48AAB7FF.4070502@extricom.com>
On Tue, 19 Aug 2008, Eran Liberty wrote:
> Steven Rostedt wrote:
> >
> > > Testing tracer sched_switch: PASSED
> > > Testing tracer ftrace: PASSED
> > > Testing dynamic ftrace: PASSED
Do you have PREEMPT_TRACER enabled, or any other tracer for that matter?
-- Steve
> > >
> > > Oops: Exception in kernel mode, sig: 11 [#1]
> > > Exsw1600
> > > Modules linked in:
> > > NIP: c00bbb20 LR: c00bbb20 CTR: 00000000
> > >
> >
^ permalink raw reply
* Re: [PATCH 1/2] rtc: rtc-ds1374: fix 'no irq' case handling
From: Peter Korsgaard @ 2008-08-19 20:01 UTC (permalink / raw)
To: Anton Vorontsov
Cc: Alessandro Zummo, Andrew Morton, linux-kernel, rtc-linux,
linuxppc-dev
In-Reply-To: <20080812161733.GA32164@oksana.dev.rtsoft.ru>
>>>>> "Anton" == Anton Vorontsov <avorontsov@ru.mvista.com> writes:
Anton> On a PowerPC board with ds1374 RTC I'm getting this error while
Anton> RTC tries to probe:
Anton> rtc-ds1374 0-0068: unable to request IRQ
Anton> This happens because I2C probing code (drivers/of/of_i2c.c) is
Anton> specifying IRQ0 for 'no irq' case, which is correct.
Anton> The driver handles this incorrectly, though. This patch fixes it.
Great, I was just about to send a similar patch. Another advantage of
using 0 for 'no irq' is for I2C_BOARD_INFO(). With that you can simply
not assign anything to .irq instead of having to set it to -1.
Acked-by: Peter Korsgaard <jacmet@sunsite.dk>
--
Bye, Peter Korsgaard
^ permalink raw reply
* Re: [PATCH 0/9] Rework PowerPC 44x board support
From: Josh Boyer @ 2008-08-19 18:45 UTC (permalink / raw)
To: Stefan Roese; +Cc: linuxppc-dev
In-Reply-To: <200808192026.12632.sr@denx.de>
On Tue, 19 Aug 2008 20:26:12 +0200
Stefan Roese <sr@denx.de> wrote:
> On Tuesday 19 August 2008, Josh Boyer wrote:
> > The following patch series reworks the board support code for PowerPC 44x
> > platforms. It eliminates a number of redundant <board>.c files and add a
> > ppc44x_simple.c file that has an explicit list of boards that are supported
> > by it. This is the same mechanism that Grant Likely has used for MPC 5200
> > boards.
> >
> > It also adds some more explicit support for Glacier and Yosemite boards, as
> > those boards were using a board level compatible property in their DTS
> > files that was a bit confusing.
> >
> > Review would be appreciated. Tested on Sequoia, and I plan on testing on
> > as many boards as I can before committing to my tree.
>
> Looks great at first glance. I'll try to do some testing here too in the next
> few days.
That would be much appreciated. I have a number of the effected
boards, but I don't have them all so any testing you can do would be
awesome.
josh
^ permalink raw reply
* Re: [PATCH 0/9] Rework PowerPC 44x board support
From: Stefan Roese @ 2008-08-19 18:26 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <cover.1219160188.git.jwboyer@linux.vnet.ibm.com>
On Tuesday 19 August 2008, Josh Boyer wrote:
> The following patch series reworks the board support code for PowerPC 44x
> platforms. It eliminates a number of redundant <board>.c files and add a
> ppc44x_simple.c file that has an explicit list of boards that are supported
> by it. This is the same mechanism that Grant Likely has used for MPC 5200
> boards.
>
> It also adds some more explicit support for Glacier and Yosemite boards, as
> those boards were using a board level compatible property in their DTS
> files that was a bit confusing.
>
> Review would be appreciated. Tested on Sequoia, and I plan on testing on
> as many boards as I can before committing to my tree.
Looks great at first glance. I'll try to do some testing here too in the next
few days.
Thanks.
Best regards,
Stefan
^ 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