[2.6 patch] sata_fsl.c: fix 8315DS workaround
Commit e7eac96e8f0e57a6e9f94943557bc2b23be31471 (ata/sata_fsl: Move MPC8315DS link speed limit workaround to specific ifdef) aimed at limiting the workaround only to the affected hardware, but since the #ifdef used a nonexisting kconfig variable it actually killed the workaround. Reported-by: Robert P. J. Day [EMAIL PROTECTED] Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- cd54dd8b6a8bca44ead212d12fe116702cc31ed7 diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index 3924e72..45878ef 100644 --- a/drivers/ata/sata_fsl.c +++ b/drivers/ata/sata_fsl.c @@ -640,7 +640,7 @@ static int sata_fsl_port_start(struct ata_port *ap) VPRINTK(HControl = 0x%x\n, ioread32(hcr_base + HCONTROL)); VPRINTK(CHBA = 0x%x\n, ioread32(hcr_base + CHBA)); -#ifdef CONFIG_MPC8315_DS +#ifdef CONFIG_MPC831x_RDB /* * Workaround for 8315DS board 3gbps link-up issue, * currently limit SATA port to GEN1 speed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [2.6 patch] sata_fsl.c: fix 8315DS workaround
On Mon, Aug 04, 2008 at 04:55:37PM +0800, Li Yang wrote: -Original Message- From: Adrian Bunk [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2008 4:46 PM To: Kalra Ashish; Li Yang; Jeff Garzik; [EMAIL PROTECTED] Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; Robert P. J. Day Subject: [2.6 patch] sata_fsl.c: fix 8315DS workaround Commit e7eac96e8f0e57a6e9f94943557bc2b23be31471 (ata/sata_fsl: Move MPC8315DS link speed limit workaround to specific ifdef) aimed at limiting the workaround only to the affected hardware, but since the #ifdef used a nonexisting kconfig variable it actually killed the workaround. This workaround is only for MPC8315_DS board which is not supported in the main line yet. We can remove the workaround if we need to do something here. Thanks, in this case my patch is complete crap. There's no need for any action. - Leo cu Adrian -- Is there not promise of rain? Ling Tan asked suddenly out of the darkness. There had been need of rain for many days. Only a promise, Lao Er said. Pearl S. Buck - Dragon Seed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
RE: [2.6 patch] sata_fsl.c: fix 8315DS workaround
-Original Message- From: Adrian Bunk [mailto:[EMAIL PROTECTED] Sent: Monday, August 04, 2008 4:46 PM To: Kalra Ashish; Li Yang; Jeff Garzik; [EMAIL PROTECTED] Cc: linuxppc-dev@ozlabs.org; [EMAIL PROTECTED]; Robert P. J. Day Subject: [2.6 patch] sata_fsl.c: fix 8315DS workaround Commit e7eac96e8f0e57a6e9f94943557bc2b23be31471 (ata/sata_fsl: Move MPC8315DS link speed limit workaround to specific ifdef) aimed at limiting the workaround only to the affected hardware, but since the #ifdef used a nonexisting kconfig variable it actually killed the workaround. This workaround is only for MPC8315_DS board which is not supported in the main line yet. We can remove the workaround if we need to do something here. - Leo Reported-by: Robert P. J. Day [EMAIL PROTECTED] Signed-off-by: Adrian Bunk [EMAIL PROTECTED] --- cd54dd8b6a8bca44ead212d12fe116702cc31ed7 diff --git a/drivers/ata/sata_fsl.c b/drivers/ata/sata_fsl.c index 3924e72..45878ef 100644 --- a/drivers/ata/sata_fsl.c +++ b/drivers/ata/sata_fsl.c @@ -640,7 +640,7 @@ static int sata_fsl_port_start(struct ata_port *ap) VPRINTK(HControl = 0x%x\n, ioread32(hcr_base + HCONTROL)); VPRINTK(CHBA = 0x%x\n, ioread32(hcr_base + CHBA)); -#ifdef CONFIG_MPC8315_DS +#ifdef CONFIG_MPC831x_RDB /* * Workaround for 8315DS board 3gbps link-up issue, * currently limit SATA port to GEN1 speed ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
Paul Collins [EMAIL PROTECTED] writes: Neil Brown [EMAIL PROTECTED] writes: Could you try removing the 'static' declaration for nfsd_acceptable and recompile? Or maybe try a different compiler? I will give these a try this evening. I built myself a nice new cross compiler: powerpc-linux-gnu-gcc-4.1 (GCC) 4.1.3 20080623 (prerelease) (Debian 4.1.2-23) and rebuilt 94ad374a0751f40d25e22e036c37f7263569d24c. Running that on the server and 2.6.26 on the client, I got yet another Oops. This one locked the machine up pretty good, so all I have is a picture: http://ondioline.org/~paul/DSCN1608.JPG -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: mISDN still breaking the allmodconfig build...
On Mon, Jul 28, 2008 at 08:49:10AM -0400, Sinan Akman wrote: Karsten Keil wrote: [...] virt_to_bus() I never got a complain before and yes I already have some patches to solve the endian issues in the HFC driver, but it was not finaly Karsten, do you have those patches available somewhere ? I could give it a try on 4xx with a 4s card in the near future. Already fixed in git://git.kernel.org/pub/scm/linux/kernel/git/kkeil/ISDN-2.6.git -- Karsten Keil SuSE Labs ISDN and VOIP development SUSE LINUX Products GmbH, Maxfeldstr.5 90409 Nuernberg, GF: Markus Rex, HRB 16746 (AG Nuernberg) ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
mv643xx_eth changes for 2.6.27
The mv643xx_eth ethernet driver has had some very heavy hacking done to it during the 2.6.27 merge window: $ wc -l linux-2.6.26/drivers/net/mv643xx_eth.c linux-2.6.27-rc1-git4/drivers/net/mv643xx_eth.c 3365 linux-2.6.26/drivers/net/mv643xx_eth.c 2653 linux-2.6.27-rc1-git4/drivers/net/mv643xx_eth.c $ diff -u linux-2.6.26/drivers/net/mv643xx_eth.c linux-2.6.27-rc1-git4/drivers/net/mv643xx_eth.c mv643xx_eth.c | 4774 -- 1 file changed, 2031 insertions(+), 2743 deletions(-) $ If you have any Linux-running device that has an mv643xx_eth in it (i.e. if it has a Marvell Discovery controller or a Marvell ARM SoC in it), please test 2.6.27-rc2 extensively (once it is released) and report whether it works for you or not. IOW, please send me success reports as well as failure reports. Thanks. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 0/3 V2] powerpc - Make the irq reverse mapping tree lockless
Hi , here is V2 of the patchset posted on July 31st updated from the comments made by Michael Ellerman. V1 - V2: - Initialize the XICS radix tree in xics code and only for that irq_host rather than doing it for all the hosts in the powerpc irq generic code (although the hosts list only contain one entry at the moment). - Add a comment in irq_radix_revmap_lookup() stating why it is safe to perform a lookup even if the radix tree has not been initialized yet. The goal of this patchset is to simplify the locking constraints on the radix tree used for IRQ reverse mapping on the pSeries machines and provide lockless access to this tree. This also solves the following BUG under preempt-rt: BUG: sleeping function called from invalid context swapper(1) at kernel/rtmutex.c:739 in_atomic():1 [0002], irqs_disabled():1 Call Trace: [c001e20f3340] [c0010370] .show_stack+0x70/0x1bc (unreliable) [c001e20f33f0] [c0049380] .__might_sleep+0x11c/0x138 [c001e20f3470] [c02a2f64] .__rt_spin_lock+0x3c/0x98 [c001e20f34f0] [c00c3f20] .kmem_cache_alloc+0x68/0x184 [c001e20f3590] [c0193f3c] .radix_tree_node_alloc+0xf0/0x144 [c001e20f3630] [c0195190] .radix_tree_insert+0x18c/0x2fc [c001e20f36f0] [c000c710] .irq_radix_revmap+0x1a4/0x1e4 [c001e20f37b0] [c003b3f0] .xics_startup+0x30/0x54 [c001e20f3840] [c008b864] .setup_irq+0x26c/0x370 [c001e20f38f0] [c008ba68] .request_irq+0x100/0x158 [c001e20f39a0] [c01ee9c0] .hvc_open+0xb4/0x148 [c001e20f3a40] [c01d72ec] .tty_open+0x200/0x368 [c001e20f3af0] [c00ce928] .chrdev_open+0x1f4/0x25c [c001e20f3ba0] [c00c8bf0] .__dentry_open+0x188/0x2c8 [c001e20f3c50] [c00c8dec] .do_filp_open+0x50/0x70 [c001e20f3d70] [c00c8e8c] .do_sys_open+0x80/0x148 [c001e20f3e20] [c000928c] .init_post+0x4c/0x100 [c001e20f3ea0] [c03c0e0c] .kernel_init+0x428/0x478 [c001e20f3f90] [c0027448] .kernel_thread+0x4c/0x68 The root cause of this bug lies in the fact that the XICS interrupt controller uses a radix tree for its reverse irq mapping and that we cannot allocate the tree nodes (even GFP_ATOMIC) with preemption disabled. In fact, we have 2 nested preemption disabling when we want to allocate a new node: - setup_irq() does a spin_lock_irqsave() before calling xics_startup() which then calls irq_radix_revmap() to insert a new node in the tree - irq_radix_revmap() also does a spin_lock_irqsave() (in irq_radix_wrlock()) before the radix_tree_insert() Also, if an IRQ gets registered before the tree is initialized (namely the IPI), it will be inserted into the tree in interrupt context once the tree have been initialized, hence the need for a spin_lock_irqsave() in the insertion path. This serie is split into 3 patches: - The first patch moves the initialization of the radix tree earlier in the boot process before any IRQ gets registered, but after the mm is up. - The second patch splits irq_radix_revmap() into its 2 components: one for lookup and one for insertion into the radix tree. - And finally, the third patch makes the radix tree fully lockless on the lookup side. Here is the diffstat for the whole patchset: arch/powerpc/include/asm/irq.h| 19 - arch/powerpc/kernel/irq.c | 130 +++-- arch/powerpc/platforms/pseries/smp.c |1 + arch/powerpc/platforms/pseries/xics.c | 17 +++-- arch/powerpc/platforms/pseries/xics.h |1 + 5 files changed, 56 insertions(+), 112 deletions(-) Thanks, Sebastien. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 1/3] powerpc - Initialize the irq radix tree earlier
The radix tree used for fast irq reverse mapping by the XICS is initialized
late in the boot process, after the first interrupt (IPI) gets registered
and after the first IPI is received.
This patch moves the initialization of the XICS radix tree earlier into
the boot process in smp_xics_probe() (the mm is already up but no interrupts
have been registered at that point) to avoid having to insert a mapping into
the tree in interrupt context. This will help in simplifying the locking
constraints and move to a lockless radix tree in subsequent patches.
Signed-off-by: Sebastien Dugue [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/kernel/irq.c | 17 -
arch/powerpc/platforms/pseries/smp.c |1 +
arch/powerpc/platforms/pseries/xics.c |5 +
arch/powerpc/platforms/pseries/xics.h |1 +
4 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index d972dec..9bef9f3 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -1016,23 +1016,6 @@ void irq_early_init(void)
get_irq_desc(i)-status |= IRQ_NOREQUEST;
}
-/* We need to create the radix trees late */
-static int irq_late_init(void)
-{
- struct irq_host *h;
- unsigned long flags;
-
- irq_radix_wrlock(flags);
- 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);
-
- return 0;
-}
-arch_initcall(irq_late_init);
-
#ifdef CONFIG_VIRQ_DEBUG
static int virq_debug_show(struct seq_file *m, void *private)
{
diff --git a/arch/powerpc/platforms/pseries/smp.c
b/arch/powerpc/platforms/pseries/smp.c
index 9d8f8c8..3d4429a 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -130,6 +130,7 @@ static void smp_xics_message_pass(int target, int msg)
static int __init smp_xics_probe(void)
{
+ xics_radix_revmap_init();
xics_request_IPIs();
return cpus_weight(cpu_possible_map);
diff --git a/arch/powerpc/platforms/pseries/xics.c
b/arch/powerpc/platforms/pseries/xics.c
index 0fc830f..d6e28f9 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -556,6 +556,11 @@ static struct irq_host_ops xics_host_ops = {
.xlate = xics_host_xlate,
};
+void __init xics_radix_revmap_init(void)
+{
+ INIT_RADIX_TREE(xics_host-revmap_data.tree, GFP_ATOMIC);
+}
+
static void __init xics_init_host(void)
{
if (firmware_has_feature(FW_FEATURE_LPAR))
diff --git a/arch/powerpc/platforms/pseries/xics.h
b/arch/powerpc/platforms/pseries/xics.h
index 1c5321a..11490be 100644
--- a/arch/powerpc/platforms/pseries/xics.h
+++ b/arch/powerpc/platforms/pseries/xics.h
@@ -19,6 +19,7 @@ extern void xics_setup_cpu(void);
extern void xics_teardown_cpu(void);
extern void xics_kexec_teardown_cpu(int secondary);
extern void xics_cause_IPI(int cpu);
+extern void xics_radix_revmap_init(void);
extern void xics_request_IPIs(void);
extern void xics_migrate_irqs_away(void);
--
1.5.5.1
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
[PATCH 2/3] powerpc - Separate the irq radix tree insertion and lookup
irq_radix_revmap() currently serves 2 purposes, irq mapping lookup
and insertion which happen in interrupt and process context respectively.
Separate the function into its 2 components, one for lookup only and one
for insertion only.
Signed-off-by: Sebastien Dugue [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/include/asm/irq.h| 18 ++--
arch/powerpc/kernel/irq.c | 46 +++-
arch/powerpc/platforms/pseries/xics.c | 11 +++-
3 files changed, 41 insertions(+), 34 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 9bef9f3..ba24efd 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -821,9 +821,6 @@ void irq_dispose_mapping(unsigned int virq)
host-revmap_data.linear.revmap[hwirq] = NO_IRQ;
break;
case IRQ_HOST_MAP_TREE:
- /* Check if radix tree allocated yet */
- if (host-revmap_data.tree.gfp_mask == 0)
- break;
irq_radix_wrlock(flags);
radix_tree_delete(host-revmap_data.tree, hwirq);
irq_radix_wrunlock(flags);
@@ -875,43 +872,44 @@ 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
+ /* Note: It is safe to call radix_tree_lookup() here, even before the
+* tree gets initialized because the struct irq_host is zallocated
+* and radix_tree_lookup() returns NULL when root-rnode is found
+* to be NULL.
+* IOW, for any interrupt taken before the tree is initialized, we
+* return NO_IRQ.
*/
- tree = host-revmap_data.tree;
- if (tree-gfp_mask == 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);
+
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;
}
[PATCH 3/3] powerpc - Make the irq reverse mapping radix tree lockless
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.
Signed-off-by: Sebastien Dugue [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/include/asm/irq.h|1 +
arch/powerpc/kernel/irq.c | 71 -
arch/powerpc/platforms/pseries/xics.c |1 +
3 files changed, 10 insertions(+), 63 deletions(-)
diff --git a/arch/powerpc/include/asm/irq.h b/arch/powerpc/include/asm/irq.h
index 0a51376..43b6062 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 ba24efd..5d63255 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;
struct irq_map_entry irq_map[NR_IRQS];
static unsigned int irq_virq_count = NR_IRQS;
static struct irq_host *irq_default_host;
@@ -583,57 +581,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)
{
@@ -788,7 +735,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;
@@ -821,9 +767,9 @@ void irq_dispose_mapping(unsigned int virq)
host-revmap_data.linear.revmap[hwirq] = NO_IRQ;
break;
case IRQ_HOST_MAP_TREE:
- 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;
}
@@ -877,7 +823,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);
@@ -888,9 +833,11 @@ unsigned int irq_radix_revmap_lookup(struct irq_host *host,
* IOW, for any interrupt taken before the tree is initialized, we
* return NO_IRQ.
*/
- 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);
-
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
On Mon, 2008-08-04 at 22:00 +1200, Paul Collins wrote: Paul Collins [EMAIL PROTECTED] writes: Neil Brown [EMAIL PROTECTED] writes: Could you try removing the 'static' declaration for nfsd_acceptable and recompile? Or maybe try a different compiler? I will give these a try this evening. I built myself a nice new cross compiler: powerpc-linux-gnu-gcc-4.1 (GCC) 4.1.3 20080623 (prerelease) (Debian 4.1.2-23) and rebuilt 94ad374a0751f40d25e22e036c37f7263569d24c. Running that on the server and 2.6.26 on the client, I got yet another Oops. This one locked the machine up pretty good, so all I have is a picture: http://ondioline.org/~paul/DSCN1608.JPG Wow. Can you try building a kernel on the server? ie. not over NFS. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] port ndfc driver to arch/powerpc
On Saturday 02 August 2008, Sean MacLennan wrote: This is a port of the ndfc driver from arch/ppc to arch/powerpc. Since arch/ppc has been removed, references to CONFIG_PPC_MERGE where removed. For an example of how to use the driver see arch/powerpc/platforms/44x/warp-nand.c . Signed-off-by: Sean MacLennan [EMAIL PROTECTED] Shouldn't this instead use the device tree, like fsl_elbc, fsl_upm and pasemi_nand do? It feels awfully backwards to hardcode this stuff in the platform source code. Arnd ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 3/3] powerpc - Make the irq reverse mapping radix tree lockless
On Mon, 2008-08-04 at 13:08 +0200, Sebastien Dugue wrote:
--- 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;
You have a tabbing issue above..
Daniel
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH] port ndfc driver to arch/powerpc
On Mon, 4 Aug 2008 18:25:02 +0200 Arnd Bergmann [EMAIL PROTECTED] wrote: Shouldn't this instead use the device tree, like fsl_elbc, fsl_upm and pasemi_nand do? It feels awfully backwards to hardcode this stuff in the platform source code. Yes, yes it should. This is just a patch to get the driver working... it is not a full blown of platform driver. Currently there is no working NDFC driver in the kernel. I felt a working driver, even if less than optimal, is better than not supporting NAND on the 44x. This driver is no worse than the arch/ppc version was, it is just no better ;) Cheers, Sean ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
Michael Ellerman [EMAIL PROTECTED] writes: On Mon, 2008-08-04 at 22:00 +1200, Paul Collins wrote: Paul Collins [EMAIL PROTECTED] writes: Neil Brown [EMAIL PROTECTED] writes: Could you try removing the 'static' declaration for nfsd_acceptable and recompile? Or maybe try a different compiler? I will give these a try this evening. I built myself a nice new cross compiler: powerpc-linux-gnu-gcc-4.1 (GCC) 4.1.3 20080623 (prerelease) (Debian 4.1.2-23) and rebuilt 94ad374a0751f40d25e22e036c37f7263569d24c. Running that on the server and 2.6.26 on the client, I got yet another Oops. This one locked the machine up pretty good, so all I have is a picture: http://ondioline.org/~paul/DSCN1608.JPG Wow. Can you try building a kernel on the server? ie. not over NFS. Built kernels on the server with native gcc 4.2.4 and 4.3.1 and repeated the build test. Both of them threw an Oops with traces like the ones we've seen before. Also, because now's about time to start shooting in the dark, I tried a cross-built kernel with CC_OPTIMIZE_FOR_SIZE disabled. That one Oopses too. Also I reseated the server's memory. Although I've been able to build kernels over NFS with 2.6.26 on the server, I've just realized I haven't tried to stress it much. I'll try a build loop when the server's running 2.6.26 this evening. -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
On Tue, Aug 05, 2008 at 08:51:23AM +1200, Paul Collins wrote: Michael Ellerman [EMAIL PROTECTED] writes: On Mon, 2008-08-04 at 22:00 +1200, Paul Collins wrote: Paul Collins [EMAIL PROTECTED] writes: Neil Brown [EMAIL PROTECTED] writes: Could you try removing the 'static' declaration for nfsd_acceptable and recompile? Or maybe try a different compiler? I will give these a try this evening. I built myself a nice new cross compiler: powerpc-linux-gnu-gcc-4.1 (GCC) 4.1.3 20080623 (prerelease) (Debian 4.1.2-23) and rebuilt 94ad374a0751f40d25e22e036c37f7263569d24c. Running that on the server and 2.6.26 on the client, I got yet another Oops. This one locked the machine up pretty good, so all I have is a picture: http://ondioline.org/~paul/DSCN1608.JPG Wow. Can you try building a kernel on the server? ie. not over NFS. Built kernels on the server with native gcc 4.2.4 and 4.3.1 and repeated the build test. But the build test itself was over nfs? (And you can't reproduce the same problem without nfs?) --b. Both of them threw an Oops with traces like the ones we've seen before. Also, because now's about time to start shooting in the dark, I tried a cross-built kernel with CC_OPTIMIZE_FOR_SIZE disabled. That one Oopses too. Also I reseated the server's memory. Although I've been able to build kernels over NFS with 2.6.26 on the server, I've just realized I haven't tried to stress it much. I'll try a build loop when the server's running 2.6.26 this evening. -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [RFC] [PATCH 0/5 V2] Huge page backed user-space stacks
On Thu, 2008-07-31 at 11:31 +0100, Mel Gorman wrote: We are a lot more reliable than we were although exact quantification is difficult because it's workload dependent. For a long time, I've been able to test bits and pieces with hugepages by allocating the pool at the time I needed it even after days of uptime. Previously this required a reboot. This is also a pretty big expansion of fs/hugetlb/ use outside of the filesystem itself. It is hacking the existing shared memory kernel-internal user to spit out effectively anonymous memory. Where do we draw the line where we stop using the filesystem for this? Other than the immediate code reuse, does it gain us anything? I have to think that actually refactoring the filesystem code and making it usable for really anonymous memory, then using *that* in these patches would be a lot more sane. Especially for someone that goes to look at it in a year. :) -- Dave ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PS3 early lock-up
On Mon, 2008-08-04 at 17:48 +0200, Geert Uytterhoeven wrote: On PS3, recent kernels lock up in the very early stage (i.e. before mere mortals get to see a working console). The kernel crashes with | kernel BUG at linux/arch/powerpc/platforms/ps3/htab.c:141! Bisecting shows this happens since: | commit a1f242ff460e4b50a045fa237c3c56cce9eabf83 | Author: Benjamin Herrenschmidt [EMAIL PROTECTED] | Date: Wed Jul 23 21:27:08 2008 -0700 | | powerpc ioremap_prot | | This adds ioremap_prot and pte_pgprot() so that one can extract protection | bits from a PTE and use them to ioremap_prot() (in order to support ptrace | of VM_IO | VM_PFNMAP as per Rik's patch). | | This moves a couple of flag checks around in the ioremap implementations | of arch/powerpc. There's a side effect of allowing non-cacheable and | non-guarded mappings on ppc32 which before would always have _PAGE_GUARDED | set whenever _PAGE_NO_CACHE is. | | (standard ioremap will still set _PAGE_GUARDED, but ioremap_prot will be | capable of setting such a non guarded mapping). Inside ps3_hpte_insert(), lv1_write_htab_entry() fails with error code 5 (LV1_ACCESS_VIOLATION) when adding the PS3 hotplug memory. debug_dump_hpte() prints for the offending hpte: | pa = 5100h | lpar = 5100h | va = adc7d4c2d000h | group = 6168h | bitmap = 0h | hpte.v = adc7d4c2d011h | hpte.r = 51000115h ^ | psize = 0h | slot = 6168h After manually reverting the offending commit, the system boots again. The only change is: | pa = 5100h | lpar = 5100h | va = adc7d4c2d000h | group = 6168h | bitmap = 0h | hpte.v = adc7d4c2d011h | hpte.r = 51000117h ^ | psize = 0h | slot = 6168h Note that when adding the initial (non-hotplug) memory, hpte.r always ends in `194', both before and after reverting the offending commit. ps3_hpte_insert() seems to be called during system initialization with the following values of rflags: - first call: 0x190 - initial memory: 0x194 (455 times) - hotplug memory: o crash: 0x115 o OK: 0x117 Do you have an idea of what's really going on? Weird... Both look incorrect. In fact, it's a bit scary... The one with the 7 at the end means that user space as RO access to the segment (oops !) and supervisor too. The one with the 5 means RO for user and RW for supervisor. That is unless your HV is munging them in strange ways... I don't know why LV1 is refusing a combination though. As for the flags, it depends what htab_bolt_mapping() is called with. Do you have a backtrace ? I'm a bit lots in the mem hotswap code trying to figure out where the mapping comes from.. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
On Mon, 2008-08-04 at 16:59 -0400, J. Bruce Fields wrote: On Tue, Aug 05, 2008 at 08:51:23AM +1200, Paul Collins wrote: Michael Ellerman [EMAIL PROTECTED] writes: On Mon, 2008-08-04 at 22:00 +1200, Paul Collins wrote: Paul Collins [EMAIL PROTECTED] writes: Neil Brown [EMAIL PROTECTED] writes: Could you try removing the 'static' declaration for nfsd_acceptable and recompile? Or maybe try a different compiler? I will give these a try this evening. I built myself a nice new cross compiler: powerpc-linux-gnu-gcc-4.1 (GCC) 4.1.3 20080623 (prerelease) (Debian 4.1.2-23) and rebuilt 94ad374a0751f40d25e22e036c37f7263569d24c. Running that on the server and 2.6.26 on the client, I got yet another Oops. This one locked the machine up pretty good, so all I have is a picture: http://ondioline.org/~paul/DSCN1608.JPG Wow. Can you try building a kernel on the server? ie. not over NFS. Built kernels on the server with native gcc 4.2.4 and 4.3.1 and repeated the build test. But the build test itself was over nfs? (And you can't reproduce the same problem without nfs?) Yeah, I'm not clear on that either. What I was aiming at was can you get it to oops somewhere else by not building over NFS - in which case we can rule NFS (more or less) out. cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PS3 early lock-up
Hi, Benjamin Herrenschmidt wrote: ps3_hpte_insert() seems to be called during system initialization with the following values of rflags: - first call: 0x190 - initial memory: 0x194 (455 times) - hotplug memory: o crash: 0x115 o OK: 0x117 Do you have an idea of what's really going on? Weird... Both look incorrect. In fact, it's a bit scary... The one with the 7 at the end means that user space as RO access to the segment (oops !) and supervisor too. The one with the 5 means RO for user and RW for supervisor. That is unless your HV is munging them in strange ways... I don't know why LV1 is refusing a combination though. As for the flags, it depends what htab_bolt_mapping() is called with. Do you have a backtrace ? I'm a bit lots in the mem hotswap code trying to figure out where the mapping comes from.. Ah, found it... It should be ok... both the mapping of the RAM itself and vmemmap_populate() should be passing _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX; Which should be 0x194. That is 0x190. 0x194 = _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX Can you find out where that stupid value comes from ? I didn't have time to look at in detail, but it fails from the ioremap call in ps3_map_htab (arch/powerpc/platfroms/ps3/htab.c): htab = (__force struct hash_pte *)ioremap_flags(htab_addr, htab_size, pgprot_val(PAGE_READONLY_X)); IIRC, lv1 doesn't allow a read/write mapping of the htab, and that is why I used pgprot_val(PAGE_READONLY_X) here. I guess the value returned from pgprot_val(PAGE_READONLY_X) changed in recent kernels, and that is what is causing the failure. Just FYI, I put these in: printk(%s:%d: flags = %x\n, __func__, __LINE__, (_PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX)); printk(%s:%d: flags = %x\n, __func__, __LINE__, pgprot_val(PAGE_READONLY_X)); and got this (and lv1_write_htab_entry failed): ps3_map_htab:288: flags = 190 ps3_map_htab:289: flags = 117 -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc - Initialize the irq radix tree earlier
On Mon, 2008-08-04 at 13:08 +0200, Sebastien Dugue wrote:
The radix tree used for fast irq reverse mapping by the XICS is initialized
late in the boot process, after the first interrupt (IPI) gets registered
and after the first IPI is received.
This patch moves the initialization of the XICS radix tree earlier into
the boot process in smp_xics_probe() (the mm is already up but no interrupts
have been registered at that point) to avoid having to insert a mapping into
the tree in interrupt context. This will help in simplifying the locking
constraints and move to a lockless radix tree in subsequent patches.
I'm not too happy with the moving of the radix tree init to platform
code.
The fact that the revmap code uses a radix tree should be mostly
transparent to the XICS code. I don't like adding this explicit code
from xics to initialize it.
I think the tree should still be initialized from generic code and it
can be done as late as we want as interrupts work without the tree being
there, they are just a bit slower.
I believe the right approach is:
- Remove the populating of the tree from the revmap function as
you already do
- Move it to irq_create_mapping() for the normal case
- For pre-existing interrupt, have the generic code that initializes
the radix tree walk through all interrupts and setup the revmap for
them. If that needs locking vs. concurrent irq_create_mapping, it's
easy to use one of the available spinlocks for that.
Cheers,
Ben.
Signed-off-by: Sebastien Dugue [EMAIL PROTECTED]
Cc: Paul Mackerras [EMAIL PROTECTED]
Cc: Benjamin Herrenschmidt [EMAIL PROTECTED]
Cc: Michael Ellerman [EMAIL PROTECTED]
---
arch/powerpc/kernel/irq.c | 17 -
arch/powerpc/platforms/pseries/smp.c |1 +
arch/powerpc/platforms/pseries/xics.c |5 +
arch/powerpc/platforms/pseries/xics.h |1 +
4 files changed, 7 insertions(+), 17 deletions(-)
diff --git a/arch/powerpc/kernel/irq.c b/arch/powerpc/kernel/irq.c
index d972dec..9bef9f3 100644
--- a/arch/powerpc/kernel/irq.c
+++ b/arch/powerpc/kernel/irq.c
@@ -1016,23 +1016,6 @@ void irq_early_init(void)
get_irq_desc(i)-status |= IRQ_NOREQUEST;
}
-/* We need to create the radix trees late */
-static int irq_late_init(void)
-{
- struct irq_host *h;
- unsigned long flags;
-
- irq_radix_wrlock(flags);
- 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);
-
- return 0;
-}
-arch_initcall(irq_late_init);
-
#ifdef CONFIG_VIRQ_DEBUG
static int virq_debug_show(struct seq_file *m, void *private)
{
diff --git a/arch/powerpc/platforms/pseries/smp.c
b/arch/powerpc/platforms/pseries/smp.c
index 9d8f8c8..3d4429a 100644
--- a/arch/powerpc/platforms/pseries/smp.c
+++ b/arch/powerpc/platforms/pseries/smp.c
@@ -130,6 +130,7 @@ static void smp_xics_message_pass(int target, int msg)
static int __init smp_xics_probe(void)
{
+ xics_radix_revmap_init();
xics_request_IPIs();
return cpus_weight(cpu_possible_map);
diff --git a/arch/powerpc/platforms/pseries/xics.c
b/arch/powerpc/platforms/pseries/xics.c
index 0fc830f..d6e28f9 100644
--- a/arch/powerpc/platforms/pseries/xics.c
+++ b/arch/powerpc/platforms/pseries/xics.c
@@ -556,6 +556,11 @@ static struct irq_host_ops xics_host_ops = {
.xlate = xics_host_xlate,
};
+void __init xics_radix_revmap_init(void)
+{
+ INIT_RADIX_TREE(xics_host-revmap_data.tree, GFP_ATOMIC);
+}
+
static void __init xics_init_host(void)
{
if (firmware_has_feature(FW_FEATURE_LPAR))
diff --git a/arch/powerpc/platforms/pseries/xics.h
b/arch/powerpc/platforms/pseries/xics.h
index 1c5321a..11490be 100644
--- a/arch/powerpc/platforms/pseries/xics.h
+++ b/arch/powerpc/platforms/pseries/xics.h
@@ -19,6 +19,7 @@ extern void xics_setup_cpu(void);
extern void xics_teardown_cpu(void);
extern void xics_kexec_teardown_cpu(int secondary);
extern void xics_cause_IPI(int cpu);
+extern void xics_radix_revmap_init(void);
extern void xics_request_IPIs(void);
extern void xics_migrate_irqs_away(void);
___
Linuxppc-dev mailing list
Linuxppc-dev@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: [PATCH 1/3] powerpc - Initialize the irq radix tree earlier
- Remove the populating of the tree from the revmap function as you already do - Move it to irq_create_mapping() for the normal case - For pre-existing interrupt, have the generic code that initializes the radix tree walk through all interrupts and setup the revmap for them. If that needs locking vs. concurrent irq_create_mapping, it's easy to use one of the available spinlocks for that. And in fact, you may even be able to avoid GFP_ATOMIC completely here and switch it to GFP_KERNEL since irq_create_mapping() can sleep afaik, provided that you avoid the spinlocking. Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: PS3 early lock-up
Which should be 0x194. That is 0x190. 0x194 = _PAGE_EXEC | _PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX Right, _PAGE_EXEC should only be set for the part covering the kernel text. In any case, it shouldn't be what you showed. Can you find out where that stupid value comes from ? I didn't have time to look at in detail, but it fails from the ioremap call in ps3_map_htab (arch/powerpc/platfroms/ps3/htab.c): htab = (__force struct hash_pte *)ioremap_flags(htab_addr, htab_size, pgprot_val(PAGE_READONLY_X)); IIRC, lv1 doesn't allow a read/write mapping of the htab, and that is why I used pgprot_val(PAGE_READONLY_X) here. Why are you mapping it in the first place btw ? Do you actually use that mapping ? I guess the value returned from pgprot_val(PAGE_READONLY_X) changed in recent kernels, and that is what is causing the failure. Ok, there's definitely something fishy about passing the PP bits down to ioremap. The reason it fails is that I no longer let _PAGE_USER go down to the mapping. However, ioremap passes those bits as-is to the hash insert code, it should instead perform the same munging as the asm hashing code does, to turn that into a supervisor only mapping. However, there is a deeper issue with what you are doing. With using only 2 PP bits, as is the case with linux, you -cannot- have a supervisor read-only mapping that isn't also readable by userspace. It's possible the newer 3 PPP bits encoding, but I don't know if Cell supports it and linux currently doesn't use it. That means that currently, your hash table is user readable... oops :-) (This is a bug with other early IO mappings too btw, I'll have to fix that). However, it appears to me that you don't use the mapping of the hash table anyway. So just remove the ioremap :-) I'll look at fixing the attribute parsing for ioremap_prot() in the long run though. Ben. Just FYI, I put these in: printk(%s:%d: flags = %x\n, __func__, __LINE__, (_PAGE_ACCESSED | _PAGE_DIRTY | _PAGE_COHERENT | PP_RWXX)); printk(%s:%d: flags = %x\n, __func__, __LINE__, pgprot_val(PAGE_READONLY_X)); and got this (and lv1_write_htab_entry failed): ps3_map_htab:288: flags = 190 ps3_map_htab:289: flags = 117 -Geoff ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
2.6.27 fixes for 4xx tree
Hi All, If you have fixes for 4xx that you want to get in the .27 kernel, please let me know soon. I have the following queued up: Sean MacLennan (3): powerpc/4xx: Cleanup Warp for i2c driver changes. powerpc/44x: Warp DTS changes for board updates powerpc/44x: Incorrect NOR offset in Warp DTS Valentine Barshak (1): powerpc/44x: Adjust warp-nand resource end address I'll also be updating all the defconfigs for 4xx in the next day or so. Then I'll ask Paul to pull. josh ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
Michael Ellerman [EMAIL PROTECTED] writes: On Mon, 2008-08-04 at 16:59 -0400, J. Bruce Fields wrote: On Tue, Aug 05, 2008 at 08:51:23AM +1200, Paul Collins wrote: Michael Ellerman [EMAIL PROTECTED] writes: On Mon, 2008-08-04 at 22:00 +1200, Paul Collins wrote: Paul Collins [EMAIL PROTECTED] writes: Neil Brown [EMAIL PROTECTED] writes: Could you try removing the 'static' declaration for nfsd_acceptable and recompile? Or maybe try a different compiler? I will give these a try this evening. I built myself a nice new cross compiler: powerpc-linux-gnu-gcc-4.1 (GCC) 4.1.3 20080623 (prerelease) (Debian 4.1.2-23) and rebuilt 94ad374a0751f40d25e22e036c37f7263569d24c. Running that on the server and 2.6.26 on the client, I got yet another Oops. This one locked the machine up pretty good, so all I have is a picture: http://ondioline.org/~paul/DSCN1608.JPG Wow. Can you try building a kernel on the server? ie. not over NFS. Built kernels on the server with native gcc 4.2.4 and 4.3.1 and repeated the build test. But the build test itself was over nfs? (And you can't reproduce the same problem without nfs?) Yeah, I'm not clear on that either. What I was aiming at was can you get it to oops somewhere else by not building over NFS - in which case we can rule NFS (more or less) out. I think may be able to rule NFS out now. I just got this Oops when Xorg started on boot. Unable to handle kernel paging request for data at address 0x0949 Faulting instruction address: 0xc0104190 Oops: Kernel access of bad area, sig: 11 [#1] PowerMac Modules linked in: snd_aoa_codec_tas snd_aoa_fabric_layout b43 snd_aoa mac80211 cfg80211 pcmcia snd_aoa_i2sbus snd_pcm_oss snd_pcm snd_page_alloc snd_aoa_soundbus yenta_socket rsrc_nonstatic pcmcia_core ssb uninorth_agp agpgart ehci_hcd ohci_hcd NIP: c0104190 LR: c0104138 CTR: c01fbd8c REGS: eee89c40 TRAP: 0300 Not tainted (2.6.27-rc1-00158-g643fbd8) MSR: 9032 EE,ME,IR,DR CR: 88088222 XER: 2000 DAR: 0949, DSISR: 4200 TASK = c1ebb840[2528] 'Xorg' THREAD: eee88000 GPR00: c0104138 eee89cf0 c1ebb840 0901 ef507d20 0007 c062 c061ca30 GPR08: ef507d08 c05ae45c 9e370001 eee89cf0 28002248 101f3ca4 101ee800 101ebf1c GPR16: eee89e2c fff4 c05d eee89d60 ffd8 eee89d68 101ebf20 ef4ebab4 GPR24: c00d0148 28088222 ef4eba40 0901 f627 ef3ee5e0 eee89cf0 NIP [c0104190] proc_lookup_de+0xe0/0xf8 LR [c0104138] proc_lookup_de+0x88/0xf8 Call Trace: [eee89cf0] [c0104138] proc_lookup_de+0x88/0xf8 (unreliable) [eee89d10] [c010467c] proc_lookup+0x34/0x4c [eee89d20] [c00c034c] do_lookup+0x1a4/0x220 [eee89d50] [c00c2010] __link_path_walk+0x18c/0xdd4 [eee89dc0] [c00c2cb0] path_walk+0x58/0xe0 [eee89df0] [c00c2e68] do_path_lookup+0x78/0x17c [eee89e20] [c00c3b58] user_path_at+0x64/0xa4 [eee89e90] [c00baa64] vfs_stat_fd+0x34/0x74 [eee89ec0] [c00bac2c] vfs_stat+0x30/0x48 [eee89ed0] [c00bac74] sys_stat64+0x30/0x5c [eee89f40] [c0013aa8] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xfc4a300 LR = 0xfc4a2b8 Instruction dump: 4e800020 3860fffe 8161 800b0004 bb6bffec 7d615b78 7c0803a6 4e800020 3d20c05b 7c641b78 3929e45c 7f83e378 913c0048 4bfc98bd 7f83e378 4bfc7dcd ---[ end trace 9be805d8b3000d04 ]--- And earlier today I got these three Oopses when I did du -sh * in my homedir: Oops: Exception in kernel mode, sig: 4 [#1] PowerMac Modules linked in: option radeon drm snd_aoa_codec_tas snd_aoa_fabric_layout b43 mac80211 snd_aoa cfg80211 pcmcia snd_aoa_i2sbus snd_pcm_oss snd_pcm snd_page_alloc snd_aoa_soundbus yenta_socket rsrc_nonstatic pcmcia_core ssb uninorth_agp agpgart ehci_hcd ohci_hcd NIP: c00d01b4 LR: c00d0148 CTR: c01fbd8c REGS: ec42bbf0 TRAP: 0700 Not tainted (2.6.27-rc1-00158-g643fbd8) MSR: 00089032 EE,ME,IR,DR CR: 24088428 XER: TASK = c1c837e0[3610] 'du' THREAD: ec42a000 GPR00: eee15e7c ec42bca0 c1c837e0 c0f1d4fc 002de7e6 ef306bb0 e9d3d104 GPR08: c065 e9d3fe84 e9d3fe7c c05d 24088422 10029cb8 10010a8c 10010f5c GPR16: ec42be3c fff4 c05d ec42bd70 ffd8 ec42bd78 1000f940 ee0c5338 GPR24: e9d3fe74 c0f0ae20 000126dc c0f1d4fc eee15e00 002de7e6 ec42bca0 NIP [c00d01b4] iget_locked+0xfc/0x148 LR [c00d0148] iget_locked+0x90/0x148 Call Trace: [ec42bca0] [c00d0148] iget_locked+0x90/0x148 (unreliable) [ec42bcd0] [c011cd60] ext3_iget+0x24/0x53c [ec42bd00] [c0120dbc] ext3_lookup+0x108/0x144 [ec42bd30] [c00c034c] do_lookup+0x1a4/0x220 [ec42bd60] [c00c22ac] __link_path_walk+0x428/0xdd4 [ec42bdd0] [c00c2cb0] path_walk+0x58/0xe0 [ec42be00] [c00c2e68] do_path_lookup+0x78/0x17c [ec42be30] [c00c3b58] user_path_at+0x64/0xa4 [ec42bea0] [c00ba884] vfs_lstat_fd+0x34/0x74 [ec42bed0] [c00bab2c] sys_fstatat64+0x88/0x90 [ec42bf40] [c0013aa8] ret_from_syscall+0x0/0x38 --- Exception: c01 at 0xff4fc1c LR = 0xff4fbb0 Instruction dump: 93d80020 3d00c065 3d60c05d 39580008 381c007c 812842d0 80ebd00c
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
On Tue, 2008-08-05 at 15:43 +1200, Paul Collins wrote: Michael Ellerman [EMAIL PROTECTED] writes: On Mon, 2008-08-04 at 16:59 -0400, J. Bruce Fields wrote: On Tue, Aug 05, 2008 at 08:51:23AM +1200, Paul Collins wrote: Michael Ellerman [EMAIL PROTECTED] writes: On Mon, 2008-08-04 at 22:00 +1200, Paul Collins wrote: Paul Collins [EMAIL PROTECTED] writes: Neil Brown [EMAIL PROTECTED] writes: Could you try removing the 'static' declaration for nfsd_acceptable and recompile? Or maybe try a different compiler? I will give these a try this evening. I built myself a nice new cross compiler: powerpc-linux-gnu-gcc-4.1 (GCC) 4.1.3 20080623 (prerelease) (Debian 4.1.2-23) and rebuilt 94ad374a0751f40d25e22e036c37f7263569d24c. Running that on the server and 2.6.26 on the client, I got yet another Oops. This one locked the machine up pretty good, so all I have is a picture: http://ondioline.org/~paul/DSCN1608.JPG Wow. Can you try building a kernel on the server? ie. not over NFS. Built kernels on the server with native gcc 4.2.4 and 4.3.1 and repeated the build test. But the build test itself was over nfs? (And you can't reproduce the same problem without nfs?) Yeah, I'm not clear on that either. What I was aiming at was can you get it to oops somewhere else by not building over NFS - in which case we can rule NFS (more or less) out. I think may be able to rule NFS out now. I just got this Oops when Xorg started on boot. Cool, that looks fairly convincing. In case anyone wants to disassemble it, I've uploaded the kernel to http://ondioline.org/~paul/vmlinux-2.6.27-rc1-00158-g643fbd8 and the config to http://ondioline.org/~paul/config-2.6.27-rc1-00158-g643fbd8 I've rebuilt a whole bunch of times in the course of this little project, but the all four Oopses in this message are from the very vmlinux linked above. I have a couple of patches applied locally (a console font and a Bluetooth HID quirk), so this is really Linus revision 94ad374a0751f40d25e22e036c37f7263569d24c. And you're _sure_ none of them has a break-everything hunk in it? :) I see you have FTRACE enabled. That's new and could potentially bugger things up without the compiler knowing, so can you turn that off. And can you enable CONFIG_CODE_PATCHING_SELFTEST and CONFIG_FTR_FIXUP_SELFTEST, that will enable tests of some code I changed that /could/ (maybe) cause random blow ups. Also, how old is the machine? Any chance you're just seeing random memory corruption? cheers -- Michael Ellerman OzLabs, IBM Australia Development Lab wwweb: http://michael.ellerman.id.au phone: +61 2 6212 1183 (tie line 70 21183) We do not inherit the earth from our ancestors, we borrow it from our children. - S.M.A.R.T Person signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
Re: nfsd, v4: oops in find_acceptable_alias, ppc32 Linux, post-2.6.27-rc1
Michael Ellerman [EMAIL PROTECTED] writes: On Tue, 2008-08-05 at 15:43 +1200, Paul Collins wrote: Michael Ellerman [EMAIL PROTECTED] writes: I think may be able to rule NFS out now. I just got this Oops when Xorg started on boot. Cool, that looks fairly convincing. In case anyone wants to disassemble it, I've uploaded the kernel to http://ondioline.org/~paul/vmlinux-2.6.27-rc1-00158-g643fbd8 and the config to http://ondioline.org/~paul/config-2.6.27-rc1-00158-g643fbd8 I've rebuilt a whole bunch of times in the course of this little project, but the all four Oopses in this message are from the very vmlinux linked above. I have a couple of patches applied locally (a console font and a Bluetooth HID quirk), so this is really Linus revision 94ad374a0751f40d25e22e036c37f7263569d24c. And you're _sure_ none of them has a break-everything hunk in it? :) Pretty sure! Here's a diffstat: $ git diff --stat HEAD^^.. drivers/video/console/Kconfig | 12 + drivers/video/console/Makefile|2 + drivers/video/console/font_neepalt10x20.c | 5392 drivers/video/console/font_neepalt12x24.c | 6416 + drivers/video/console/fonts.c |8 + include/linux/font.h |6 +- net/bluetooth/hidp/core.c |6 + 7 files changed, 11841 insertions(+), 1 deletions(-) I see you have FTRACE enabled. That's new and could potentially bugger things up without the compiler knowing, so can you turn that off. And can you enable CONFIG_CODE_PATCHING_SELFTEST and CONFIG_FTR_FIXUP_SELFTEST, that will enable tests of some code I changed that /could/ (maybe) cause random blow ups. I'll try these out. Also, how old is the machine? Any chance you're just seeing random memory corruption? It's about four years old. It was in storage for about six months and I got it repaired a few weeks ago (display cable and inverter). The sort of crazy crap I've been reporting certainly smacks of memory corruption. But on the other hand, 2.6.25 (Debian's) and 2.6.26 (my own) have been trouble-free. -- Paul Collins Wellington, New Zealand Dag vijandelijk luchtschip de huismeester is dood ___ Linuxppc-dev mailing list Linuxppc-dev@ozlabs.org https://ozlabs.org/mailman/listinfo/linuxppc-dev
