LinuxPPC-Dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH] [POWERPC] convert transfer_to_handler into a macro
From: Kumar Gala @ 2008-04-29 13:56 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev

We need to have unique transfer_to_handler paths for each exception level
that is supported.  We need to use the proper xSRR0/1 depending on which
exception level the interrupt was from.  The macro conversion lets up
templatize this code path.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---

Paul,

I request you apply this for v2.6.26.  I know its a bit late in the game
but I'd prefer to get this in so reduce churn later.  Also, I've built this
version on pmac_defconfig, ppc40x_defconfig, and ppc44x_config and compared
the objdump output to ensure that the code is identical before and after
this patch.

- k

 arch/powerpc/kernel/entry_32.S |  191 ++++++++++++++++++++++------------------
 1 files changed, 106 insertions(+), 85 deletions(-)

diff --git a/arch/powerpc/kernel/entry_32.S b/arch/powerpc/kernel/entry_32.S
index 0c8614d..7710a02 100644
--- a/arch/powerpc/kernel/entry_32.S
+++ b/arch/powerpc/kernel/entry_32.S
@@ -43,6 +43,111 @@
 #define LOAD_MSR_KERNEL(r, x)	li r,(x)
 #endif

+#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
+#ifdef CONFIG_SMP
+#define SMP_ADJUST_GLOBAL_DBCR0						       \
+	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT);				       \
+	lwz	r9,TI_CPU(r9);						       \
+	slwi	r9,r9,3;						       \
+	add	r11,r11,r9;
+#else
+#define SMP_ADJUST_GLOBAL_DBCR0
+#endif
+#define HANDLE_DBCR							       \
+	/* Check to see if the dbcr0 register is set up to debug.  Use the     \
+	   internal debug mode bit to do this. */			       \
+	lwz	r12,THREAD_DBCR0(r12);					       \
+	andis.	r12,r12,DBCR0_IDM@h;					       \
+	beq+	3f;							       \
+	/* From user and task is ptraced - load up global dbcr0 */	       \
+	li	r12,-1;			/* clear all pending debug events */   \
+	mtspr	SPRN_DBSR,r12;						       \
+	lis	r11,global_dbcr0@ha;					       \
+	tophys(r11,r11);						       \
+	addi	r11,r11,global_dbcr0@l;					       \
+	SMP_ADJUST_GLOBAL_DBCR0;					       \
+	lwz	r12,0(r11);						       \
+	mtspr	SPRN_DBCR0,r12;						       \
+	lwz	r12,4(r11);						       \
+	addi	r12,r12,-1;						       \
+	stw	r12,4(r11);
+#else
+#define HANDLE_DBCR
+#endif
+
+#ifdef CONFIG_6xx
+#define CHECK_DOZE_NAP							       \
+	rlwinm	r9,r1,0,0,31-THREAD_SHIFT;				       \
+	tophys(r9,r9);			/* check local flags */		       \
+	lwz	r12,TI_LOCAL_FLAGS(r9);					       \
+	mtcrf	0x01,r12;						       \
+	bt-	31-TLF_NAPPING,4f;
+#define RESTORE_DOZE_NAP						       \
+4:	rlwinm	r12,r12,0,~_TLF_NAPPING;				       \
+	stw	r12,TI_LOCAL_FLAGS(r9);					       \
+	b	power_save_6xx_restore;
+#else
+#define RESTORE_DOZE_NAP
+#define CHECK_DOZE_NAP
+#endif /* CONFIG_6xx */
+
+/*
+ * This code finishes saving the registers to the exception frame
+ * and jumps to the appropriate handler for the exception, turning
+ * on address translation.
+ * Note that we rely on the caller having set cr0.eq iff the exception
+ * occurred in kernel mode (i.e. MSR:PR = 0).
+ */
+
+#define	TRANSFER_TO_HANDLER(prefix, exc_lvl_srr0, exc_lvl_srr1, exc_lvl_rfi)   \
+	.globl	prefix##transfer_to_handler_full;			       \
+prefix##transfer_to_handler_full:					       \
+	SAVE_NVGPRS(r11);						       \
+	/* fall through */						       \
+									       \
+	.globl	prefix##transfer_to_handler;				       \
+prefix##transfer_to_handler:						       \
+	stw	r2,GPR2(r11);						       \
+	stw	r12,_NIP(r11);						       \
+	stw	r9,_MSR(r11);						       \
+	andi.	r2,r9,MSR_PR;						       \
+	mfctr	r12;							       \
+	mfspr	r2,SPRN_XER;						       \
+	stw	r12,_CTR(r11);						       \
+	stw	r2,_XER(r11);						       \
+	mfspr	r12,SPRN_SPRG3;						       \
+	addi	r2,r12,-THREAD;						       \
+	tovirt(r2,r2);			/* set r2 to current */		       \
+	beq	2f;			/* if from user, fix up THREAD.regs */ \
+									       \
+	addi	r11,r1,STACK_FRAME_OVERHEAD;				       \
+	stw	r11,PT_REGS(r12);					       \
+	HANDLE_DBCR;							       \
+	b	3f;							       \
+									       \
+2:	/* if from kernel, check interrupted DOZE/NAP mode and		       \
+         * check for stack overflow					       \
+         */								       \
+	lwz	r9,KSP_LIMIT(r12);					       \
+	cmplw	r1,r9;			/* if r1 <= ksp_limit */	       \
+	ble-	stack_ovf;		/* then the kernel stack overflowed */ \
+5:									       \
+	CHECK_DOZE_NAP;							       \
+									       \
+	.globl prefix##transfer_to_handler_cont;			       \
+prefix##transfer_to_handler_cont:					       \
+3:									       \
+	mflr	r9;							       \
+	lwz	r11,0(r9);		/* virtual address of handler */       \
+	lwz	r9,4(r9);		/* where to go when done */	       \
+	mtspr	exc_lvl_srr0,r11;					       \
+	mtspr	exc_lvl_srr1,r10;					       \
+	mtlr	r9;							       \
+	SYNC;								       \
+	exc_lvl_rfi;			/* jump to handler, enable MMU */      \
+									       \
+	RESTORE_DOZE_NAP;
+
 #ifdef CONFIG_BOOKE
 #include "head_booke.h"
 #define TRANSFER_TO_HANDLER_EXC_LEVEL(exc_level)	\
@@ -80,91 +185,7 @@ crit_transfer_to_handler:
 	/* fall through */
 #endif

-/*
- * This code finishes saving the registers to the exception frame
- * and jumps to the appropriate handler for the exception, turning
- * on address translation.
- * Note that we rely on the caller having set cr0.eq iff the exception
- * occurred in kernel mode (i.e. MSR:PR = 0).
- */
-	.globl	transfer_to_handler_full
-transfer_to_handler_full:
-	SAVE_NVGPRS(r11)
-	/* fall through */
-
-	.globl	transfer_to_handler
-transfer_to_handler:
-	stw	r2,GPR2(r11)
-	stw	r12,_NIP(r11)
-	stw	r9,_MSR(r11)
-	andi.	r2,r9,MSR_PR
-	mfctr	r12
-	mfspr	r2,SPRN_XER
-	stw	r12,_CTR(r11)
-	stw	r2,_XER(r11)
-	mfspr	r12,SPRN_SPRG3
-	addi	r2,r12,-THREAD
-	tovirt(r2,r2)			/* set r2 to current */
-	beq	2f			/* if from user, fix up THREAD.regs */
-	addi	r11,r1,STACK_FRAME_OVERHEAD
-	stw	r11,PT_REGS(r12)
-#if defined(CONFIG_40x) || defined(CONFIG_BOOKE)
-	/* Check to see if the dbcr0 register is set up to debug.  Use the
-	   internal debug mode bit to do this. */
-	lwz	r12,THREAD_DBCR0(r12)
-	andis.	r12,r12,DBCR0_IDM@h
-	beq+	3f
-	/* From user and task is ptraced - load up global dbcr0 */
-	li	r12,-1			/* clear all pending debug events */
-	mtspr	SPRN_DBSR,r12
-	lis	r11,global_dbcr0@ha
-	tophys(r11,r11)
-	addi	r11,r11,global_dbcr0@l
-#ifdef CONFIG_SMP
-	rlwinm	r9,r1,0,0,(31-THREAD_SHIFT)
-	lwz	r9,TI_CPU(r9)
-	slwi	r9,r9,3
-	add	r11,r11,r9
-#endif
-	lwz	r12,0(r11)
-	mtspr	SPRN_DBCR0,r12
-	lwz	r12,4(r11)
-	addi	r12,r12,-1
-	stw	r12,4(r11)
-#endif
-	b	3f
-
-2:	/* if from kernel, check interrupted DOZE/NAP mode and
-         * check for stack overflow
-         */
-	lwz	r9,KSP_LIMIT(r12)
-	cmplw	r1,r9			/* if r1 <= ksp_limit */
-	ble-	stack_ovf		/* then the kernel stack overflowed */
-5:
-#ifdef CONFIG_6xx
-	rlwinm	r9,r1,0,0,31-THREAD_SHIFT
-	tophys(r9,r9)			/* check local flags */
-	lwz	r12,TI_LOCAL_FLAGS(r9)
-	mtcrf	0x01,r12
-	bt-	31-TLF_NAPPING,4f
-#endif /* CONFIG_6xx */
-	.globl transfer_to_handler_cont
-transfer_to_handler_cont:
-3:
-	mflr	r9
-	lwz	r11,0(r9)		/* virtual address of handler */
-	lwz	r9,4(r9)		/* where to go when done */
-	mtspr	SPRN_SRR0,r11
-	mtspr	SPRN_SRR1,r10
-	mtlr	r9
-	SYNC
-	RFI				/* jump to handler, enable MMU */
-
-#ifdef CONFIG_6xx
-4:	rlwinm	r12,r12,0,~_TLF_NAPPING
-	stw	r12,TI_LOCAL_FLAGS(r9)
-	b	power_save_6xx_restore
-#endif
+	TRANSFER_TO_HANDLER(, SPRN_SRR0, SPRN_SRR1, RFI);

 /*
  * On kernel stack overflow, load up an initial stack pointer
-- 
1.5.4.1

^ permalink raw reply related

* [PATCH] of/gpio: use dynamic base allocation
From: Anton Vorontsov @ 2008-04-29 14:05 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev, David Miller

Since gpiolib-dynamic-gpio-number-allocation.patch -mm patch was recently
merged into Linus' tree (commit 8d0aab2f16c4fa170f32e7a74a52cd0122bbafef),
we can use dynamic GPIO base allocation now.

This, in turn, removes number of gpios per chip constraint.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 drivers/of/gpio.c |   38 +-------------------------------------
 1 files changed, 1 insertions(+), 37 deletions(-)

diff --git a/drivers/of/gpio.c b/drivers/of/gpio.c
index 000681e..1c9cab8 100644
--- a/drivers/of/gpio.c
+++ b/drivers/of/gpio.c
@@ -137,38 +137,6 @@ int of_gpio_simple_xlate(struct of_gpio_chip *of_gc, struct device_node *np,
 }
 EXPORT_SYMBOL(of_gpio_simple_xlate);
 
-/* Should be sufficient for now, later we'll use dynamic bases. */
-#if defined(CONFIG_PPC32) || defined(CONFIG_SPARC32)
-#define GPIOS_PER_CHIP 32
-#else
-#define GPIOS_PER_CHIP 64
-#endif
-
-static int of_get_gpiochip_base(struct device_node *np)
-{
-	struct device_node *gc = NULL;
-	int gpiochip_base = 0;
-
-	while ((gc = of_find_all_nodes(gc))) {
-		if (!of_get_property(gc, "gpio-controller", NULL))
-			continue;
-
-		if (gc != np) {
-			gpiochip_base += GPIOS_PER_CHIP;
-			continue;
-		}
-
-		of_node_put(gc);
-
-		if (gpiochip_base >= ARCH_NR_GPIOS)
-			return -ENOSPC;
-
-		return gpiochip_base;
-	}
-
-	return -ENOENT;
-}
-
 /**
  * of_mm_gpiochip_add - Add memory mapped GPIO chip (bank)
  * @np:		device node of the GPIO chip
@@ -205,11 +173,7 @@ int of_mm_gpiochip_add(struct device_node *np,
 	if (!mm_gc->regs)
 		goto err1;
 
-	gc->base = of_get_gpiochip_base(np);
-	if (gc->base < 0) {
-		ret = gc->base;
-		goto err1;
-	}
+	gc->base = -1;
 
 	if (!of_gc->xlate)
 		of_gc->xlate = of_gpio_simple_xlate;
-- 
1.5.5.1

^ permalink raw reply related

* Re: [PATCH] devres: support addresses greater than an unsigned long via dev_ioremap
From: Kumar Gala @ 2008-04-29 14:08 UTC (permalink / raw)
  To: Greg KH
  Cc: Andrew Morton, Tejun Heo, lkml Mailing List, Jesse Barnes,
	linuxppc-dev@ozlabs.org list, Jeff Garzik
In-Reply-To: <4816C214.60806@pobox.com>


On Apr 29, 2008, at 1:37 AM, Jeff Garzik wrote:
> Tejun Heo wrote:
>> Kumar Gala wrote:
>>> Use a resource_size_t instead of unsigned long since some arch's are
>>> capable of having ioremap deal with addresses greater than the  
>>> size of a
>>> unsigned long.
>>>
>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>> Acked-by: Tejun Heo <htejun@gmail.com>
>
> Fine with me, too.
>
> I think devres changes should go via GregKH (device core) or Jesse  
> (PCI) rather than my libata tree, unless there are obvious  
> dependencies...

GregKH will you handle pushing this to Linus.  Its a pretty trivial  
patch and would be nice to go into 2.6.26.  I would also consider it a  
bug fix of shorts for any driver using devres and resource_size_t  
being typedef'd to u64 on a 32-bit processor.

- k

^ permalink raw reply

* Re: Enabling 64 bit data type for dma_addr_t on non PPC64 architecture
From: Becky Bruce @ 2008-04-29 15:14 UTC (permalink / raw)
  To: benh; +Cc: linuxppc-dev, Tushar Tyagi
In-Reply-To: <1209181131.5420.42.camel@pasglop>


On Apr 25, 2008, at 10:38 PM, Benjamin Herrenschmidt wrote:
>
> On Fri, 2008-04-25 at 19:52 -0700, Tushar Tyagi wrote:
>> Hello,
>> I'm working a new DMA hardware for PPC processors.
>> The processor is a 32 bit architecture having 40 bit physical address
>> space.
>> So we need the 32 bit processor code base but we want the type
>> dma_addr_t to represent 64 bit data, without enabling the  
>> CONFIG_PPC64
>> flag.
>
> That shouldn't be a big issue, we already support 64 bits resources,
> extending dma_addr_t shouldn't too hard.
>
>> We want to use the Linux generic DMA layer to offload DMA  
>> operations to
>> the hw and the Linux code path goes through function
>> dma_async_memcpy_buf_to_buf and then dma_map_single.
>>
>> Currently the dma_map_single function has 2 versions based upon
>> CONFIG_PPC64 defined or not.
>>
>> Is it possible to reuse the CONFIG_PPC64 based code only pertaining  
>> to
>> DMA by doing the following:
>
> It's possible, it might be a good idea even as it would allow to have
> different implementations for different busses, which is in fact  
> needed
> for some things like 4xx if we start changing the mapping between
> different PCI bridges vs. SoCs. In fact, I think there's been some
> patches from Becky Bruce posted in februrary for doing just that,  
> which
> I totally forgot to review...
>
>> Add a new flag called CONFIG_DMA64 along with CONFIG_PPC64 and
>> __powerpc64__ flags, enabling our code to use the generic DMA layer  
>> with
>> 64 bit data type for dma_addr_t.
>>
>> With the above modification, the function dma_map_single starts
>> returning 64 bit data type instead of 32.
>>
>> Do you have any comments or suggestions ?
>
> I'd suggest working with Becky on her initial patch and using that as
> the basis for your stuff. I'll try to give it a good review asap.

Actually, Ben, wait on that review - I've made significant changes to  
those patches, including some bugfixes for HIGHMEM and will be posting  
the revised version soon (hopefully later today or tomorrow).   I'm  
behind a bit on the top-of-tree so I'll need to bring them up to date  
and do some testing before I post.  I think the newer version is  
cleaner than the last but can still probably use some improvement.

I've also got a patch that enables larger physical addressing in  
general - it changes the page table/mmu handling to allow for larger  
physical addresses on MPC8641; BookE parts will need a slightly  
different set of changes (some of which are already in place, but I've  
not done any work/testing on BookE at this point).  I'll try to get a  
version of that out this week as well - it needs some cleanup and  
testing on the latest tree.

Cheers,
Becky

^ permalink raw reply

* Re: [git pull] Please pull powerpc.git master branch
From: Linus Torvalds @ 2008-04-29 15:21 UTC (permalink / raw)
  To: Paul Mackerras; +Cc: linuxppc-dev, akpm, linux-kernel
In-Reply-To: <18455.1713.268188.906051@cargo.ozlabs.ibm.com>



On Tue, 29 Apr 2008, Paul Mackerras wrote:
> 
> git://git.kernel.org/pub/scm/linux/kernel/git/paulus/powerpc.git master

Umm, where did the diffstat go? I really want to see it to compare against 
what I get. I checked the shortlog and everything matches, but please, 
keep the diffstat coming too.

		Linus

^ permalink raw reply

* Re: [PATCH] devres: support addresses greater than an unsigned long via dev_ioremap
From: Greg KH @ 2008-04-29 15:23 UTC (permalink / raw)
  To: Kumar Gala
  Cc: Andrew Morton, Tejun Heo, lkml Mailing List, Jesse Barnes,
	linuxppc-dev@ozlabs.org list, Jeff Garzik
In-Reply-To: <C415A4D5-CE5A-4E48-B5D5-0B9A6C7A5CA6@kernel.crashing.org>

On Tue, Apr 29, 2008 at 09:08:14AM -0500, Kumar Gala wrote:
>
> On Apr 29, 2008, at 1:37 AM, Jeff Garzik wrote:
>> Tejun Heo wrote:
>>> Kumar Gala wrote:
>>>> Use a resource_size_t instead of unsigned long since some arch's are
>>>> capable of having ioremap deal with addresses greater than the size of a
>>>> unsigned long.
>>>>
>>>> Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
>>> Acked-by: Tejun Heo <htejun@gmail.com>
>>
>> Fine with me, too.
>>
>> I think devres changes should go via GregKH (device core) or Jesse (PCI) 
>> rather than my libata tree, unless there are obvious dependencies...
>
> GregKH will you handle pushing this to Linus.  Its a pretty trivial patch 
> and would be nice to go into 2.6.26.  I would also consider it a bug fix of 
> shorts for any driver using devres and resource_size_t being typedef'd to 
> u64 on a 32-bit processor.

Sure, I'd be glad to.  But I don't see the patch, care to resend it to
me?

thanks,

greg k-h

^ permalink raw reply

* [PATCH][RESEND] devres: support addresses greater than an unsigned long via dev_ioremap
From: Kumar Gala @ 2008-04-29 15:25 UTC (permalink / raw)
  To: Greg KH
  Cc: Andrew Morton, Tejun Heo, lkml Mailing List, Jesse Barnes,
	linuxppc-dev@ozlabs.org list, Jeff Garzik
In-Reply-To: <20080429152331.GC11329@kroah.com>

Use a resource_size_t instead of unsigned long since some arch's are
capable of having ioremap deal with addresses greater than the size of a
unsigned long.

Signed-off-by: Kumar Gala <galak@kernel.crashing.org>
---

For GregKH to actually get the patch.

- k

 include/linux/io.h |    4 ++--
 lib/devres.c       |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/include/linux/io.h b/include/linux/io.h
index e3b2dda..831f57c 100644
--- a/include/linux/io.h
+++ b/include/linux/io.h
@@ -58,9 +58,9 @@ static inline void devm_ioport_unmap(struct device *dev, void __iomem *addr)
 }
 #endif

-void __iomem * devm_ioremap(struct device *dev, unsigned long offset,
+void __iomem * devm_ioremap(struct device *dev, resource_size_t offset,
 			    unsigned long size);
-void __iomem * devm_ioremap_nocache(struct device *dev, unsigned long offset,
+void __iomem * devm_ioremap_nocache(struct device *dev, resource_size_t offset,
 				    unsigned long size);
 void devm_iounmap(struct device *dev, void __iomem *addr);
 int check_signature(const volatile void __iomem *io_addr,
diff --git a/lib/devres.c b/lib/devres.c
index edc27a5..26c87c4 100644
--- a/lib/devres.c
+++ b/lib/devres.c
@@ -20,7 +20,7 @@ static int devm_ioremap_match(struct device *dev, void *res, void *match_data)
  *
  * Managed ioremap().  Map is automatically unmapped on driver detach.
  */
-void __iomem *devm_ioremap(struct device *dev, unsigned long offset,
+void __iomem *devm_ioremap(struct device *dev, resource_size_t offset,
 			   unsigned long size)
 {
 	void __iomem **ptr, *addr;
@@ -49,7 +49,7 @@ EXPORT_SYMBOL(devm_ioremap);
  * Managed ioremap_nocache().  Map is automatically unmapped on driver
  * detach.
  */
-void __iomem *devm_ioremap_nocache(struct device *dev, unsigned long offset,
+void __iomem *devm_ioremap_nocache(struct device *dev, resource_size_t offset,
 				   unsigned long size)
 {
 	void __iomem **ptr, *addr;
-- 
1.5.4.1

^ permalink raw reply related

* [PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs
From: Stefan Roscher @ 2008-04-29 15:44 UTC (permalink / raw)
  To: LinuxPPC-Dev, LKML, OF-General, Roland Dreier, OF-EWG; +Cc: fenkes, raisch



Signed-off-by: Stefan Roscher <stefan.roscher at de.ibm.com>
---
 drivers/infiniband/hw/ehca/ehca_classes.h |    5 ++++
 drivers/infiniband/hw/ehca/ehca_cq.c      |   10 ++++++++
 drivers/infiniband/hw/ehca/ehca_main.c    |   36 +++++++++++++++++++++++++++-
 drivers/infiniband/hw/ehca/ehca_qp.c      |   10 ++++++++
 4 files changed, 59 insertions(+), 2 deletions(-)

diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
index 3d6d946..00bab60 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -66,6 +66,7 @@ struct ehca_av;
 #include "ehca_irq.h"
 
 #define EHCA_EQE_CACHE_SIZE 20
+#define EHCA_MAX_NUM_QUEUES 0xffff
 
 struct ehca_eqe_cache_entry {
 	struct ehca_eqe *eqe;
@@ -127,6 +128,8 @@ struct ehca_shca {
 	/* MR pgsize: bit 0-3 means 4K, 64K, 1M, 16M respectively */
 	u32 hca_cap_mr_pgsize;
 	int max_mtu;
+	atomic_t num_cqs;
+	atomic_t num_qps;
 };
 
 struct ehca_pd {
@@ -344,6 +347,8 @@ extern int ehca_use_hp_mr;
 extern int ehca_scaling_code;
 extern int ehca_lock_hcalls;
 extern int ehca_nr_ports;
+extern int ehca_max_cq;
+extern int ehca_max_qp;
 
 struct ipzu_queue_resp {
 	u32 qe_size;      /* queue entry size */
diff --git a/drivers/infiniband/hw/ehca/ehca_cq.c b/drivers/infiniband/hw/ehca/ehca_cq.c
index ec0cfcf..5b4f9a3 100644
--- a/drivers/infiniband/hw/ehca/ehca_cq.c
+++ b/drivers/infiniband/hw/ehca/ehca_cq.c
@@ -132,6 +132,14 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int cqe, int comp_vector,
 	if (cqe >= 0xFFFFFFFF - 64 - additional_cqe)
 		return ERR_PTR(-EINVAL);
 
+	if (atomic_read(&shca->num_cqs) >= ehca_max_cq) {
+		ehca_err(device, "Unable to create CQ, max number of %i "
+			"CQs reached.", ehca_max_cq);
+		ehca_err(device, "To increase the maximum number of CQs "
+			"use the number_of_cqs module parameter.\n");
+		return ERR_PTR(-ENOSPC);
+	}
+
 	my_cq = kmem_cache_zalloc(cq_cache, GFP_KERNEL);
 	if (!my_cq) {
 		ehca_err(device, "Out of memory for ehca_cq struct device=%p",
@@ -286,6 +294,7 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int cqe, int comp_vector,
 		}
 	}
 
+	atomic_inc(&shca->num_cqs);
 	return cq;
 
 create_cq_exit4:
@@ -359,6 +368,7 @@ int ehca_destroy_cq(struct ib_cq *cq)
 	ipz_queue_dtor(NULL, &my_cq->ipz_queue);
 	kmem_cache_free(cq_cache, my_cq);
 
+	atomic_dec(&shca->num_cqs);
 	return 0;
 }
 
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c
index 6504897..401907f 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -68,6 +68,8 @@ int ehca_port_act_time = 30;
 int ehca_static_rate   = -1;
 int ehca_scaling_code  = 0;
 int ehca_lock_hcalls   = -1;
+int ehca_max_cq        = -1;
+int ehca_max_qp        = -1;
 
 module_param_named(open_aqp1,     ehca_open_aqp1,     bool, S_IRUGO);
 module_param_named(debug_level,   ehca_debug_level,   int,  S_IRUGO);
@@ -79,6 +81,8 @@ module_param_named(poll_all_eqs,  ehca_poll_all_eqs,  bool, S_IRUGO);
 module_param_named(static_rate,   ehca_static_rate,   int,  S_IRUGO);
 module_param_named(scaling_code,  ehca_scaling_code,  bool, S_IRUGO);
 module_param_named(lock_hcalls,   ehca_lock_hcalls,   bool, S_IRUGO);
+module_param_named(number_of_cqs, ehca_max_cq,        int, S_IRUGO);
+module_param_named(number_of_qps, ehca_max_qp,        int, S_IRUGO);
 
 MODULE_PARM_DESC(open_aqp1,
 		 "Open AQP1 on startup (default: no)");
@@ -104,6 +108,12 @@ MODULE_PARM_DESC(scaling_code,
 MODULE_PARM_DESC(lock_hcalls,
 		 "Serialize all hCalls made by the driver "
 		 "(default: autodetect)");
+MODULE_PARM_DESC(number_of_cqs,
+		"Max number of CQs which can be allocated "
+		"(default: autodetect)");
+MODULE_PARM_DESC(number_of_qps,
+		"Max number of QPs which can be allocated "
+		"(default: autodetect)");
 
 DEFINE_RWLOCK(ehca_qp_idr_lock);
 DEFINE_RWLOCK(ehca_cq_idr_lock);
@@ -355,6 +365,25 @@ static int ehca_sense_attributes(struct ehca_shca *shca)
 		if (rblock->memory_page_size_supported & pgsize_map[i])
 			shca->hca_cap_mr_pgsize |= pgsize_map[i + 1];
 
+	/* Set maximum number of CQs and QPs to calculate EQ size */
+	if (ehca_max_qp == -1)
+		ehca_max_qp = min_t(int, rblock->max_qp, EHCA_MAX_NUM_QUEUES);
+	else if (ehca_max_qp < 1 || ehca_max_qp > rblock->max_qp) {
+		ehca_gen_err("Requested number of QPs is out of range (1 - %i) "
+			"specified by HW", rblock->max_qp);
+		ret = -EINVAL;
+		goto sense_attributes1;
+	}
+
+	if (ehca_max_cq == -1)
+		ehca_max_cq = min_t(int, rblock->max_cq, EHCA_MAX_NUM_QUEUES);
+	else if (ehca_max_cq < 1 || ehca_max_cq > rblock->max_cq) {
+		ehca_gen_err("Requested number of CQs is out of range (1 - %i) "
+			"specified by HW", rblock->max_cq);
+		ret = -EINVAL;
+		goto sense_attributes1;
+	}
+
 	/* query max MTU from first port -- it's the same for all ports */
 	port = (struct hipz_query_port *)rblock;
 	h_ret = hipz_h_query_port(shca->ipz_hca_handle, 1, port);
@@ -684,7 +713,7 @@ static int __devinit ehca_probe(struct of_device *dev,
 	struct ehca_shca *shca;
 	const u64 *handle;
 	struct ib_pd *ibpd;
-	int ret, i;
+	int ret, i, eq_size;
 
 	handle = of_get_property(dev->node, "ibm,hca-handle", NULL);
 	if (!handle) {
@@ -705,6 +734,8 @@ static int __devinit ehca_probe(struct of_device *dev,
 		return -ENOMEM;
 	}
 	mutex_init(&shca->modify_mutex);
+	atomic_set(&shca->num_cqs, 0);
+	atomic_set(&shca->num_qps, 0);
 	for (i = 0; i < ARRAY_SIZE(shca->sport); i++)
 		spin_lock_init(&shca->sport[i].mod_sqp_lock);
 
@@ -724,8 +755,9 @@ static int __devinit ehca_probe(struct of_device *dev,
 		goto probe1;
 	}
 
+	eq_size = 2 * ehca_max_cq + 4 * ehca_max_qp;
 	/* create event queues */
-	ret = ehca_create_eq(shca, &shca->eq, EHCA_EQ, 2048);
+	ret = ehca_create_eq(shca, &shca->eq, EHCA_EQ, eq_size);
 	if (ret) {
 		ehca_err(&shca->ib_device, "Cannot create EQ.");
 		goto probe1;
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index 57bef11..73d9c4a 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -421,6 +421,14 @@ static struct ehca_qp *internal_create_qp(
 	u32 swqe_size = 0, rwqe_size = 0, ib_qp_num;
 	unsigned long flags;
 
+	if (atomic_read(&shca->num_qps) >= ehca_max_qp) {
+		ehca_err(pd->device, "Unable to create QP, max number of %i "
+			 "QPs reached.", ehca_max_qp);
+		ehca_err(pd->device, "To increase the maximum number of QPs "
+			 "use the number_of_qps module parameter.\n");
+		return ERR_PTR(-ENOSPC);
+	}
+
 	if (init_attr->create_flags)
 		return ERR_PTR(-EINVAL);
 
@@ -797,6 +805,7 @@ static struct ehca_qp *internal_create_qp(
 		}
 	}
 
+	atomic_inc(&shca->num_qps);
 	return my_qp;
 
 create_qp_exit6:
@@ -1948,6 +1957,7 @@ static int internal_destroy_qp(struct ib_device *dev, struct ehca_qp *my_qp,
 	if (HAS_SQ(my_qp))
 		ipz_queue_dtor(my_pd, &my_qp->ipz_squeue);
 	kmem_cache_free(qp_cache, my_qp);
+	atomic_dec(&shca->num_qps);
 	return 0;
 }
 
-- 
1.5.5

^ permalink raw reply related

* RE: Virtex4FX12LC hangs in calibrating delay loop
From: Stephen Neuendorffer @ 2008-04-29 15:47 UTC (permalink / raw)
  To: wangyanlong, linuxppc-embedded
In-Reply-To: <16955743.post@talk.nabble.com>

[-- Attachment #1: Type: text/plain, Size: 2364 bytes --]


I think I've seen this happen when the boot code doesn't have the workarounds for the cache errata.  I'm not sure if that code ever made
it into grant's git server, but it's definitely is in the xilinx git tree at git.xilinx.com.

Steve

-----Original Message-----
From: linuxppc-embedded-bounces+stephen=neuendorffer.name@ozlabs.org on behalf of wangyanlong
Sent: Tue 4/29/2008 1:53 AM
To: linuxppc-embedded@ozlabs.org
Subject: Re: Virtex4FX12LC hangs in calibrating delay loop
 

I meet the same problem as yours ,  have you fix your problem now ??? I am
keep trying !!!!

Thomas Glanzmann wrote:
> 
> Hello,
> I used the HEAD secretlabs kernel and used ml403 defconfig. I still see
> no serial output from the _kernel_ on the serial console. But I do see
> output from the in kernel embedded boot loader "load_kernel". I typed in
> stop in xmd and got an instruction pointer which points to:
> 
>         c00045a0 <__delay>:
>         c00045a0:       2c 03 00 00     cmpwi   r3,0
>         c00045a4:       7c 69 03 a6     mtctr   r3
>         c00045a8:       4d 82 00 20     beqlr
>         c00045ac:       42 00 00 00     bdnz-   c00045ac <__delay+0xc>      
> <<<<<<<<
>         c00045b0:       4e 80 00 20     blr
> 
> So I guess it is the calibrating delay loop and I am not sure. I can
> reproduce
> this. It is always in this function. Now I wonder is my board missing
> timer interrupts? What could be the reason for this. And of course one
> much more important question:
> 
>         - Is the serial console initialized before or after the
>           calibrating delay loop?
> 
> Is there a way to get a backtrace out of this? If that is the case what
> do I have to do? Recompile the Kernel with frame pointers and attach
> gdb?
> 
>         Thomas
> _______________________________________________
> Linuxppc-embedded mailing list
> Linuxppc-embedded@ozlabs.org
> https://ozlabs.org/mailman/listinfo/linuxppc-embedded
> 
> 

-- 
View this message in context: http://www.nabble.com/Virtex4FX12LC-hangs-in-calibrating-delay-loop-tp11235297p16955743.html
Sent from the linuxppc-embedded mailing list archive at Nabble.com.

_______________________________________________
Linuxppc-embedded mailing list
Linuxppc-embedded@ozlabs.org
https://ozlabs.org/mailman/listinfo/linuxppc-embedded



[-- Attachment #2: Type: text/html, Size: 4076 bytes --]

^ permalink raw reply

* [PATCH 1/3] [NET] uli526x: initialize the hardware prior to requesting interrupts
From: Anton Vorontsov @ 2008-04-29 15:53 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: netdev, linuxppc-dev

The firmware on MPC8610HPCD boards enables ULI ethernet and leaves it
in some funky state before booting Linux. For drivers, it's always good
idea to (re)initialize the hardware prior to requesting interrupts.

This patch fixes the following oops:

Oops: Kernel access of bad area, sig: 11 [#1]
MPC86xx HPCD
NIP: c0172820 LR: c017287c CTR: 00000000
[...]
NIP [c0172820] allocate_rx_buffer+0x2c/0xb0
LR [c017287c] allocate_rx_buffer+0x88/0xb0
Call Trace:
[df82bdc0] [c017287c] allocate_rx_buffer+0x88/0xb0 (unreliable)
[df82bde0] [c0173000] uli526x_interrupt+0xe4/0x49c
[df82be20] [c0045418] request_irq+0xf0/0x114
[df82be50] [c01737b0] uli526x_open+0x48/0x160
[df82be70] [c0201184] dev_open+0xb0/0xe8
[df82be80] [c0200104] dev_change_flags+0x90/0x1bc
[df82bea0] [c035fab0] ip_auto_config+0x214/0xef4
[df82bf60] [c03421c8] kernel_init+0xc4/0x2ac
[df82bff0] [c0010834] kernel_thread+0x44/0x60
Instruction dump:
4e800020 9421ffe0 7c0802a6 bfa10014 7c7e1b78 90010024 80030060 83e30054
2b80002f 419d0078 3fa0c039 48000058 <907f0010> 80630088 2f830000 419e0014

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 drivers/net/tulip/uli526x.c |    8 ++++----
 1 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/drivers/net/tulip/uli526x.c b/drivers/net/tulip/uli526x.c
index a59c1f2..1f077ac 100644
--- a/drivers/net/tulip/uli526x.c
+++ b/drivers/net/tulip/uli526x.c
@@ -434,10 +434,6 @@ static int uli526x_open(struct net_device *dev)
 
 	ULI526X_DBUG(0, "uli526x_open", 0);
 
-	ret = request_irq(dev->irq, &uli526x_interrupt, IRQF_SHARED, dev->name, dev);
-	if (ret)
-		return ret;
-
 	/* system variable init */
 	db->cr6_data = CR6_DEFAULT | uli526x_cr6_user_set;
 	db->tx_packet_cnt = 0;
@@ -456,6 +452,10 @@ static int uli526x_open(struct net_device *dev)
 	/* Initialize ULI526X board */
 	uli526x_init(dev);
 
+	ret = request_irq(dev->irq, &uli526x_interrupt, IRQF_SHARED, dev->name, dev);
+	if (ret)
+		return ret;
+
 	/* Active System Interface */
 	netif_wake_queue(dev);
 
-- 
1.5.5.1

^ permalink raw reply related

* [PATCH 2/3] [NET] uli526x: fix endianness issues in the setup frame
From: Anton Vorontsov @ 2008-04-29 15:53 UTC (permalink / raw)
  To: Jeff Garzik; +Cc: netdev, linuxppc-dev

This patch fixes uli526x driver's issues on a PowerPC boards: uli chip
is unable to receive the packets.

It appears that send_frame_filter prepares the setup frame in the
endianness unsafe manner. On a big endian machines we should shift
the address nibble by two bytes.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 drivers/net/tulip/uli526x.c |   30 ++++++++++++++++++------------
 1 files changed, 18 insertions(+), 12 deletions(-)

diff --git a/drivers/net/tulip/uli526x.c b/drivers/net/tulip/uli526x.c
index 1f077ac..2511ca7 100644
--- a/drivers/net/tulip/uli526x.c
+++ b/drivers/net/tulip/uli526x.c
@@ -1368,6 +1368,12 @@ static void update_cr6(u32 cr6_data, unsigned long ioaddr)
  *	This setup frame initialize ULI526X address filter mode
  */
 
+#ifdef __BIG_ENDIAN
+#define FLT_SHIFT 16
+#else
+#define FLT_SHIFT 0
+#endif
+
 static void send_filter_frame(struct net_device *dev, int mc_cnt)
 {
 	struct uli526x_board_info *db = netdev_priv(dev);
@@ -1384,27 +1390,27 @@ static void send_filter_frame(struct net_device *dev, int mc_cnt)
 
 	/* Node address */
 	addrptr = (u16 *) dev->dev_addr;
-	*suptr++ = addrptr[0];
-	*suptr++ = addrptr[1];
-	*suptr++ = addrptr[2];
+	*suptr++ = addrptr[0] << FLT_SHIFT;
+	*suptr++ = addrptr[1] << FLT_SHIFT;
+	*suptr++ = addrptr[2] << FLT_SHIFT;
 
 	/* broadcast address */
-	*suptr++ = 0xffff;
-	*suptr++ = 0xffff;
-	*suptr++ = 0xffff;
+	*suptr++ = 0xffff << FLT_SHIFT;
+	*suptr++ = 0xffff << FLT_SHIFT;
+	*suptr++ = 0xffff << FLT_SHIFT;
 
 	/* fit the multicast address */
 	for (mcptr = dev->mc_list, i = 0; i < mc_cnt; i++, mcptr = mcptr->next) {
 		addrptr = (u16 *) mcptr->dmi_addr;
-		*suptr++ = addrptr[0];
-		*suptr++ = addrptr[1];
-		*suptr++ = addrptr[2];
+		*suptr++ = addrptr[0] << FLT_SHIFT;
+		*suptr++ = addrptr[1] << FLT_SHIFT;
+		*suptr++ = addrptr[2] << FLT_SHIFT;
 	}
 
 	for (; i<14; i++) {
-		*suptr++ = 0xffff;
-		*suptr++ = 0xffff;
-		*suptr++ = 0xffff;
+		*suptr++ = 0xffff << FLT_SHIFT;
+		*suptr++ = 0xffff << FLT_SHIFT;
+		*suptr++ = 0xffff << FLT_SHIFT;
 	}
 
 	/* prepare the setup frame */
-- 
1.5.5.1

^ permalink raw reply related

* [PATCH 3/3] [POWERPC] 86xx: mpc8610_hpcd: use ULI526X driver for on-board ethernet
From: Anton Vorontsov @ 2008-04-29 15:53 UTC (permalink / raw)
  To: Kumar Gala; +Cc: netdev, Jeff Garzik, linuxppc-dev

As of current mainline tree, TULIP driver is unusable on MPC8610HPCD
boards. There is a patch[1] floating around (and also included in the
BSP), which tries to heal the situation, though the ethernet is still
unusable. Practically it takes ages to mount NFS filesystem:

VFS: Mounted root (nfs filesystem).
Freeing unused kernel memory: 180k init
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 not responding, still trying
nfs: server 10.0.0.2 OK
nfs: server 10.0.0.2 not responding, still trying

So, instead of trying to add uli526x functionality into TULIP driver
(which is already bloated enough), I fixed existing ULI526X driver
and now it works perfectly well here.

[1] http://www.bitshrine.org/gpp/0024-MPC8610-ETH-Lyra-native-ethernet.txt

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---

This is for powerpc tree.

 arch/powerpc/configs/mpc8610_hpcd_defconfig |    7 ++-----
 1 files changed, 2 insertions(+), 5 deletions(-)

diff --git a/arch/powerpc/configs/mpc8610_hpcd_defconfig b/arch/powerpc/configs/mpc8610_hpcd_defconfig
index 9270afe..f9e53bd 100644
--- a/arch/powerpc/configs/mpc8610_hpcd_defconfig
+++ b/arch/powerpc/configs/mpc8610_hpcd_defconfig
@@ -567,14 +567,11 @@ CONFIG_MII=y
 # CONFIG_NET_VENDOR_3COM is not set
 CONFIG_NET_TULIP=y
 # CONFIG_DE2104X is not set
-CONFIG_TULIP=y
-# CONFIG_TULIP_MWI is not set
-CONFIG_TULIP_MMIO=y
-# CONFIG_TULIP_NAPI is not set
+# CONFIG_TULIP is not set
 # CONFIG_DE4X5 is not set
 # CONFIG_WINBOND_840 is not set
 # CONFIG_DM9102 is not set
-# CONFIG_ULI526X is not set
+CONFIG_ULI526X=y
 # CONFIG_HP100 is not set
 # CONFIG_IBM_NEW_EMAC_ZMII is not set
 # CONFIG_IBM_NEW_EMAC_RGMII is not set
-- 
1.5.5.1

^ permalink raw reply related

* Re: [PATCH] devres: support addresses greater than an unsigned long via dev_ioremap
From: Jon Loeliger @ 2008-04-29 15:56 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev@ozlabs.org list
In-Reply-To: <C415A4D5-CE5A-4E48-B5D5-0B9A6C7A5CA6@kernel.crashing.org>

Kumar Gala wrote:
>
> Its a pretty trivial 
> patch and would be nice to go into 2.6.26.  I would also consider it a 
> bug fix of shorts for any driver

Looked like a bugfix of longs to me... :-)

jdl

^ permalink raw reply

* [PATCH] [IDE] alim15x3: disable init_hwif_ali15x3 for PowerPC
From: Anton Vorontsov @ 2008-04-29 16:19 UTC (permalink / raw)
  To: Bartlomiej Zolnierkiewicz; +Cc: linux-ide, linuxppc-dev

We don't need init_hwif_ali15x3() on the PowerPC systems either.

Before:

ALI15X3: IDE controller (0x10b9:0x5229 rev 0xc8) at  PCI slot 0001:03:1f.0
ALI15X3: 100% native mode on irq 19
    ide0: BM-DMA at 0x1120-0x1127
    ide1: BM-DMA at 0x1128-0x112f
hda: SONY DVD RW AW-Q170A, ATAPI CD/DVD-ROM drive
hda: UDMA/66 mode selected
ide0: Disabled unable to get IRQ 14.
ide0: failed to initialize IDE interface
ide1: Disabled unable to get IRQ 15.
ide1: failed to initialize IDE interface

After:

ALI15X3: IDE controller (0x10b9:0x5229 rev 0xc8) at  PCI slot 0001:03:1f.0
ALI15X3: 100% native mode on irq 19
    ide0: BM-DMA at 0x1120-0x1127
    ide1: BM-DMA at 0x1128-0x112f
hda: SONY DVD RW AW-Q170A, ATAPI CD/DVD-ROM drive
hda: UDMA/66 mode selected
ide0 at 0x1100-0x1107,0x110a on irq 19
ide1 at 0x1110-0x1117,0x111a on irq 19
hda: ATAPI 48X DVD-ROM DVD-R CD-R/RW drive, 2048kB Cache

ide0 works well, though I can't test ide1, it isn't traced out on
the board.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 drivers/ide/pci/alim15x3.c |   10 +++++-----
 1 files changed, 5 insertions(+), 5 deletions(-)

diff --git a/drivers/ide/pci/alim15x3.c b/drivers/ide/pci/alim15x3.c
index b36a22b..c1922f9 100644
--- a/drivers/ide/pci/alim15x3.c
+++ b/drivers/ide/pci/alim15x3.c
@@ -412,14 +412,14 @@ static u8 __devinit ali_cable_detect(ide_hwif_t *hwif)
 	return cbl;
 }
 
-#ifndef CONFIG_SPARC64
+#if !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC)
 /**
  *	init_hwif_ali15x3	-	Initialize the ALI IDE x86 stuff
  *	@hwif: interface to configure
  *
  *	Obtain the IRQ tables for an ALi based IDE solution on the PC
  *	class platforms. This part of the code isn't applicable to the
- *	Sparc systems
+ *	Sparc and PowerPC systems.
  */
 
 static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
@@ -463,7 +463,9 @@ static void __devinit init_hwif_ali15x3 (ide_hwif_t *hwif)
 			hwif->irq = irq;
 	}
 }
-#endif
+#else
+#define init_hwif_ali15x3 NULL
+#endif /* !defined(CONFIG_SPARC64) && !defined(CONFIG_PPC) */
 
 /**
  *	init_dma_ali15x3	-	set up DMA on ALi15x3
@@ -517,9 +519,7 @@ static const struct ide_dma_ops ali_dma_ops = {
 static const struct ide_port_info ali15x3_chipset __devinitdata = {
 	.name		= "ALI15X3",
 	.init_chipset	= init_chipset_ali15x3,
-#ifndef CONFIG_SPARC64
 	.init_hwif	= init_hwif_ali15x3,
-#endif
 	.init_dma	= init_dma_ali15x3,
 	.port_ops	= &ali_port_ops,
 	.pio_mask	= ATA_PIO5,
-- 
1.5.5.1

^ permalink raw reply related

* [PATCH] [POWERPC] 86xx: mpc8610_hpcd: add support for PCI Express x8 slot
From: Anton Vorontsov @ 2008-04-29 16:41 UTC (permalink / raw)
  To: Kumar Gala; +Cc: linuxppc-dev

This patch adds pcie node which is resposible for PCI-E x8 slot
functioning. Though, this was tested using only x1 SKY2 NIC.

Signed-off-by: Anton Vorontsov <avorontsov@ru.mvista.com>
---
 arch/powerpc/boot/dts/mpc8610_hpcd.dts |   21 +++++++++++++++++++++
 1 files changed, 21 insertions(+), 0 deletions(-)

diff --git a/arch/powerpc/boot/dts/mpc8610_hpcd.dts b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
index 1f2f1e0..fff0572 100644
--- a/arch/powerpc/boot/dts/mpc8610_hpcd.dts
+++ b/arch/powerpc/boot/dts/mpc8610_hpcd.dts
@@ -21,6 +21,7 @@
 		serial1 = &serial1;
 		pci0 = &pci0;
 		pci1 = &pci1;
+		pci2 = &pci2;
 	};
 
 	cpus {
@@ -322,4 +323,24 @@
 			};
 		};
 	};
+
+	pci2: pcie@e0009000 {
+		#address-cells = <3>;
+		#size-cells = <2>;
+		#interrupt-cells = <1>;
+		device_type = "pci";
+		compatible = "fsl,mpc8641-pcie";
+		reg = <0xe0009000 0x00001000>;
+		ranges = <0x02000000 0 0x90000000 0x90000000 0 0x10000000
+			  0x01000000 0 0x00000000 0xe2000000 0 0x00100000>;
+		bus-range = <0 255>;
+		interrupt-map-mask = <0xf800 0 0 7>;
+		interrupt-map = <0x0000 0 0 1 &mpic 4 1
+				 0x0000 0 0 2 &mpic 5 1
+				 0x0000 0 0 3 &mpic 6 1
+				 0x0000 0 0 4 &mpic 7 1>;
+		interrupt-parent = <&mpic>;
+		interrupts = <25 2>;
+		clock-frequency = <33333333>;
+	};
 };
-- 
1.5.5.1

^ permalink raw reply related

* Re: [PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs
From: Roland Dreier @ 2008-04-29 16:43 UTC (permalink / raw)
  To: Stefan Roscher; +Cc: fenkes, LKML, OF-EWG, LinuxPPC-Dev, raisch, OF-General
In-Reply-To: <200804291744.17235.ossrosch@linux.vnet.ibm.com>

 > 
 > Signed-off-by: Stefan Roscher <stefan.roscher at de.ibm.com>

Kind of an inadequate changelog ;)

Is this a fix or an enhancement or what?

 > +	if (atomic_read(&shca->num_cqs) >= ehca_max_cq) {

 > +	if (atomic_read(&shca->num_qps) >= ehca_max_qp) {

These are racy in the sense that multiple simultaneous calls to
create_cq/create_qp might end up exceeding the ehca_max_cq limit.  Is
that an issue?

You could close the race by using atomic_add_unless() and testing the
return value (and being careful to do atomic_dec() on error paths after
you bump num_cqs/num_qps).

 - R.

^ permalink raw reply

* EXT_IRQ0 @ MPC834x
From: Andre Schwarz @ 2008-04-29 16:44 UTC (permalink / raw)
  To: linux-ppc list

All,

actually I'm having trouble getting the IRQ0 work on a MPC8343 with
2.6.25-rc8.
There's an external PCI device connected to it ....


Regarding to the manual IRQ0 is somewhat special and has Vector 48 assigned.

Therefore my dts entry for this device looks like :

interrupt-map = <0x5800 0 0 1 &ipic 0x30 0x8
                                 ... >;

Having a look on virq mapping gives :

mvBL-M7> cat /sys/kernel/debug/powerpc/virq_mapping
virq   hwirq    chip name        host name
   16  0x0000e   IPIC            /soc@e0000000/pic@700
   17  0x0000f   IPIC            /soc@e0000000/pic@700
   18  0x00009   IPIC            /soc@e0000000/pic@700
   20  0x00010   IPIC            /soc@e0000000/pic@700
   32  0x00020   IPIC            /soc@e0000000/pic@700
   33  0x00021   IPIC            /soc@e0000000/pic@700
   34  0x00022   IPIC            /soc@e0000000/pic@700
   38  0x00026   IPIC            /soc@e0000000/pic@700
   48  0x00030   IPIC            /soc@e0000000/pic@700


After loading the device driver (=mvbcdma) the irq shows up correctly.

mvBL-M7> cat /proc/interrupts
           CPU0
 16:        603   IPIC   Level     i2c-mpc
 17:          8   IPIC   Level     i2c-mpc
 18:        295   IPIC   Level     serial
 20:        341   IPIC   Level     mpc83xx_spi
 32:          2   IPIC   Level     enet_tx
 33:          3   IPIC   Level     enet_rx
 34:          0   IPIC   Level     enet_error
 38:          0   IPIC   Level     ehci_hcd:usb1
 48:          0   IPIC   Level     mvbcdma0
BAD:          0


As soon as the device generates an interrupt I get :

irq 48: nobody cared (try booting with the "irqpoll" option)
handlers:
[<d18d66e8>] (mvbcdma_irq+0x0/0x180 [mvbcdma])
Disabling IRQ #48


The handler _would_ have returned IRQ_RETVAL(1).
Obviously the handler isn't called at all - but why ?


Using "nm" on the kernel module gives :

000006e8 t mvbcdma_irq

->offset 0x6e8 inside module matches with output regarding handler.


Any help is welcome !


regards,
Andre Schwarz












MATRIX VISION GmbH, Talstraße 16, DE-71570 Oppenweiler  - Registergericht: Amtsgericht Stuttgart, HRB 271090
Geschäftsführer: Gerhard Thullner, Werner Armingeon, Uwe Furtner

^ permalink raw reply

* [PATCH]  Fix a potential issue in mpc52xx uart driver
From: Andrew Liu @ 2008-04-29  7:36 UTC (permalink / raw)
  To: grant.likely, tnt; +Cc: linuxppc-dev

mpc52xx_uart_int and __uart_put_char both try to acquire the
port->lock. Therefore the function sequence of:

mpc52xx_uart_int--> ...-->flush_to_ldisc-->...-->__uart_put_char

can potentially trigger a deadlock. To avoid this deadlock a fix
similar to that found in the 8250.c serial driver is applied. The
deadlock is avoided by releasing the lock before pushing a buffer
and reacquiring it when completed.

Signed-off-by: Andrew Liu <shengping.liu@windriver.com>

diff --git a/drivers/serial/mpc52xx_uart.c b/drivers/serial/mpc52xx_uart.c
index d93b357..5f95e53 100644
--- a/drivers/serial/mpc52xx_uart.c
+++ b/drivers/serial/mpc52xx_uart.c
@@ -783,7 +783,9 @@ mpc52xx_uart_int_rx_chars(struct uart_port *port)
                 }
         }

+       spin_unlock(&port->lock);
         tty_flip_buffer_push(tty);
+       spin_lock(&port->lock);

         return psc_ops->raw_rx_rdy(port);
  }

^ permalink raw reply related

* Re: [PATCH] [POWERPC] Add struct iommu_table argument to iommu_map_sg()
From: Olof Johansson @ 2008-04-29 17:54 UTC (permalink / raw)
  To: Mark Nelson; +Cc: linuxppc-dev
In-Reply-To: <4816AF79.502@au1.ibm.com>

On Tue, Apr 29, 2008 at 03:17:45PM +1000, Mark Nelson wrote:
> Make iommu_map_sg take a struct iommu_table. It did so before commit
> 740c3ce66700640a6e6136ff679b067e92125794 (iommu sg merging: ppc: make
> iommu respect the segment size limits).
>
> This stops the function looking in the archdata.dma_data for the iommu
> table because in the future it will be called with a device that has
> no table there.

The logical thing would be to add the archdata.dma_data to said device
instead, no? Without seeing the rest of the code that makes use of it
it's hard to tell anyway, so please post that.

> This also has the nice side effect of making iommu_map_sg() match the
> other map functions.

Consistency is good, but I wonder if the opposite wouldn't be the better
way to go here: always just pass down just the dev pointer instead. The
table can be reached from it.


-Olof

^ permalink raw reply

* cross tool netbsd 3.0 target
From: Joel Parker @ 2008-04-29 17:35 UTC (permalink / raw)
  To: linuxppc-dev

[-- Attachment #1: Type: text/plain, Size: 422 bytes --]

With the demo-ppc405.sh I can create a cross compiler for gnu/linux does anyone know how to build one for netbsd 3.0. (ie. what to put in for the target in the .dat file)

-- Joel Parker




      ____________________________________________________________________________________
Be a better friend, newshound, and 
know-it-all with Yahoo! Mobile.  Try it now.  http://mobile.yahoo.com/;_ylt=Ahu06i62sR8HDtDypao8Wcj9tAcJ

[-- Attachment #2: Type: text/html, Size: 602 bytes --]

^ permalink raw reply

* Re: cross tool netbsd 3.0 target
From: Kumar Gala @ 2008-04-29 17:50 UTC (permalink / raw)
  To: Joel Parker; +Cc: linuxppc-dev
In-Reply-To: <143351.62316.qm@web50109.mail.re2.yahoo.com>


On Apr 29, 2008, at 12:35 PM, Joel Parker wrote:
> With the demo-ppc405.sh I can create a cross compiler for gnu/linux  
> does anyone know how to build one for netbsd 3.0. (ie. what to put  
> in for the target in the .dat file)

It seems like asking this on the netbsd list would be more appropriate.

- k

^ permalink raw reply

* Re: [PATCH 3/3] [POWERPC] 86xx: mpc8610_hpcd: use ULI526X driver for on-board ethernet
From: Kumar Gala @ 2008-04-29 17:52 UTC (permalink / raw)
  To: Anton Vorontsov; +Cc: netdev, Jeff Garzik, linuxppc-dev
In-Reply-To: <20080429155333.GC28166@polina.dev.rtsoft.ru>


On Apr 29, 2008, at 10:53 AM, Anton Vorontsov wrote:
>  floating around (and also included in the
> BSP), which tries to heal the situation, though the ethernet is still
> unusable. Practically it takes ages to mount NFS filesystem:
>
> VFS: Mounted root (nfs filesystem).
> Freeing unused kernel memory: 180k init
> nfs: server 10.0.0.2 not responding, still trying
> nfs: server 10.0.0.2 OK
> nfs: server 10.0.0.2 not responding, still trying
> nfs: server 10.0.0.2 not responding, still trying
> nfs: server 10.0.0.2 not responding, still trying
> nfs: server 10.0.0.2 not responding, still trying
> nfs: server 10.0.0.2 OK
> nfs: server 10.0.0.2 not responding, still trying
>
> So, instead of trying to add uli526x functionality into TULIP driver
> (which is already bloated enough), I fixed existing ULI526X driver
> and now it works perfectly well here.

I'm assuming patches that fix the uli526x driver have been accepted by  
jeff.

- k

^ permalink raw reply

* [REPOST][PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs
From: Stefan Roscher @ 2008-04-29 18:15 UTC (permalink / raw)
  To: Roland Dreier, LinuxPPC-Dev, LKML, OF-General, OF-EWG; +Cc: fenkes, raisch
In-Reply-To: <adafxt4y5kx.fsf@cisco.com>

If a lot of QPs fall into Error state at once and the EQ of the respective
HCA is too small, it might overrun, causing the eHCA driver to stop
processing completion events and call application software's completion
handlers, effectively causing traffic to stop.

Fix this by limiting available QPs and CQs to a customizable max count,
and determining EQ size based on these counts and a worst-case assumption.

Signed-off-by: Stefan Roscher <stefan.roscher at de.ibm.com>
---

Reposted based on Roland's comments:
- use atomic_add_unless instead of atomic_read
- inf% changelog increase ;)

 drivers/infiniband/hw/ehca/ehca_classes.h |    5 ++++
 drivers/infiniband/hw/ehca/ehca_cq.c      |   11 +++++++++
 drivers/infiniband/hw/ehca/ehca_main.c    |   36 +++++++++++++++++++++++++++-
 drivers/infiniband/hw/ehca/ehca_qp.c      |   26 +++++++++++++++++++-
 4 files changed, 74 insertions(+), 4 deletions(-)

diff --git a/drivers/infiniband/hw/ehca/ehca_classes.h b/drivers/infiniband/hw/ehca/ehca_classes.h
index 3d6d946..00bab60 100644
--- a/drivers/infiniband/hw/ehca/ehca_classes.h
+++ b/drivers/infiniband/hw/ehca/ehca_classes.h
@@ -66,6 +66,7 @@ struct ehca_av;
 #include "ehca_irq.h"
 
 #define EHCA_EQE_CACHE_SIZE 20
+#define EHCA_MAX_NUM_QUEUES 0xffff
 
 struct ehca_eqe_cache_entry {
 	struct ehca_eqe *eqe;
@@ -127,6 +128,8 @@ struct ehca_shca {
 	/* MR pgsize: bit 0-3 means 4K, 64K, 1M, 16M respectively */
 	u32 hca_cap_mr_pgsize;
 	int max_mtu;
+	atomic_t num_cqs;
+	atomic_t num_qps;
 };
 
 struct ehca_pd {
@@ -344,6 +347,8 @@ extern int ehca_use_hp_mr;
 extern int ehca_scaling_code;
 extern int ehca_lock_hcalls;
 extern int ehca_nr_ports;
+extern int ehca_max_cq;
+extern int ehca_max_qp;
 
 struct ipzu_queue_resp {
 	u32 qe_size;      /* queue entry size */
diff --git a/drivers/infiniband/hw/ehca/ehca_cq.c b/drivers/infiniband/hw/ehca/ehca_cq.c
index ec0cfcf..5540b27 100644
--- a/drivers/infiniband/hw/ehca/ehca_cq.c
+++ b/drivers/infiniband/hw/ehca/ehca_cq.c
@@ -132,10 +132,19 @@ struct ib_cq *ehca_create_cq(struct ib_device *device, int cqe, int comp_vector,
 	if (cqe >= 0xFFFFFFFF - 64 - additional_cqe)
 		return ERR_PTR(-EINVAL);
 
+	if (!atomic_add_unless(&shca->num_cqs, 1, ehca_max_cq)) {
+		ehca_err(device, "Unable to create CQ, max number of %i "
+			"CQs reached.", ehca_max_cq);
+		ehca_err(device, "To increase the maximum number of CQs "
+			"use the number_of_cqs module parameter.\n");
+		return ERR_PTR(-ENOSPC);
+	}
+
 	my_cq = kmem_cache_zalloc(cq_cache, GFP_KERNEL);
 	if (!my_cq) {
 		ehca_err(device, "Out of memory for ehca_cq struct device=%p",
 			 device);
+		atomic_dec(&shca->num_cqs);
 		return ERR_PTR(-ENOMEM);
 	}
 
@@ -305,6 +314,7 @@ create_cq_exit2:
 create_cq_exit1:
 	kmem_cache_free(cq_cache, my_cq);
 
+	atomic_dec(&shca->num_cqs);
 	return cq;
 }
 
@@ -359,6 +369,7 @@ int ehca_destroy_cq(struct ib_cq *cq)
 	ipz_queue_dtor(NULL, &my_cq->ipz_queue);
 	kmem_cache_free(cq_cache, my_cq);
 
+	atomic_dec(&shca->num_cqs);
 	return 0;
 }
 
diff --git a/drivers/infiniband/hw/ehca/ehca_main.c b/drivers/infiniband/hw/ehca/ehca_main.c
index 6504897..482103e 100644
--- a/drivers/infiniband/hw/ehca/ehca_main.c
+++ b/drivers/infiniband/hw/ehca/ehca_main.c
@@ -68,6 +68,8 @@ int ehca_port_act_time = 30;
 int ehca_static_rate   = -1;
 int ehca_scaling_code  = 0;
 int ehca_lock_hcalls   = -1;
+int ehca_max_cq        = -1;
+int ehca_max_qp        = -1;
 
 module_param_named(open_aqp1,     ehca_open_aqp1,     bool, S_IRUGO);
 module_param_named(debug_level,   ehca_debug_level,   int,  S_IRUGO);
@@ -79,6 +81,8 @@ module_param_named(poll_all_eqs,  ehca_poll_all_eqs,  bool, S_IRUGO);
 module_param_named(static_rate,   ehca_static_rate,   int,  S_IRUGO);
 module_param_named(scaling_code,  ehca_scaling_code,  bool, S_IRUGO);
 module_param_named(lock_hcalls,   ehca_lock_hcalls,   bool, S_IRUGO);
+module_param_named(number_of_cqs, ehca_max_cq,        int,  S_IRUGO);
+module_param_named(number_of_qps, ehca_max_qp,        int,  S_IRUGO);
 
 MODULE_PARM_DESC(open_aqp1,
 		 "Open AQP1 on startup (default: no)");
@@ -104,6 +108,12 @@ MODULE_PARM_DESC(scaling_code,
 MODULE_PARM_DESC(lock_hcalls,
 		 "Serialize all hCalls made by the driver "
 		 "(default: autodetect)");
+MODULE_PARM_DESC(number_of_cqs,
+		"Max number of CQs which can be allocated "
+		"(default: autodetect)");
+MODULE_PARM_DESC(number_of_qps,
+		"Max number of QPs which can be allocated "
+		"(default: autodetect)");
 
 DEFINE_RWLOCK(ehca_qp_idr_lock);
 DEFINE_RWLOCK(ehca_cq_idr_lock);
@@ -355,6 +365,25 @@ static int ehca_sense_attributes(struct ehca_shca *shca)
 		if (rblock->memory_page_size_supported & pgsize_map[i])
 			shca->hca_cap_mr_pgsize |= pgsize_map[i + 1];
 
+	/* Set maximum number of CQs and QPs to calculate EQ size */
+	if (ehca_max_qp == -1)
+		ehca_max_qp = min_t(int, rblock->max_qp, EHCA_MAX_NUM_QUEUES);
+	else if (ehca_max_qp < 1 || ehca_max_qp > rblock->max_qp) {
+		ehca_gen_err("Requested number of QPs is out of range (1 - %i) "
+			"specified by HW", rblock->max_qp);
+		ret = -EINVAL;
+		goto sense_attributes1;
+	}
+
+	if (ehca_max_cq == -1)
+		ehca_max_cq = min_t(int, rblock->max_cq, EHCA_MAX_NUM_QUEUES);
+	else if (ehca_max_cq < 1 || ehca_max_cq > rblock->max_cq) {
+		ehca_gen_err("Requested number of CQs is out of range (1 - %i) "
+			"specified by HW", rblock->max_cq);
+		ret = -EINVAL;
+		goto sense_attributes1;
+	}
+
 	/* query max MTU from first port -- it's the same for all ports */
 	port = (struct hipz_query_port *)rblock;
 	h_ret = hipz_h_query_port(shca->ipz_hca_handle, 1, port);
@@ -684,7 +713,7 @@ static int __devinit ehca_probe(struct of_device *dev,
 	struct ehca_shca *shca;
 	const u64 *handle;
 	struct ib_pd *ibpd;
-	int ret, i;
+	int ret, i, eq_size;
 
 	handle = of_get_property(dev->node, "ibm,hca-handle", NULL);
 	if (!handle) {
@@ -705,6 +734,8 @@ static int __devinit ehca_probe(struct of_device *dev,
 		return -ENOMEM;
 	}
 	mutex_init(&shca->modify_mutex);
+	atomic_set(&shca->num_cqs, 0);
+	atomic_set(&shca->num_qps, 0);
 	for (i = 0; i < ARRAY_SIZE(shca->sport); i++)
 		spin_lock_init(&shca->sport[i].mod_sqp_lock);
 
@@ -724,8 +755,9 @@ static int __devinit ehca_probe(struct of_device *dev,
 		goto probe1;
 	}
 
+	eq_size = 2 * ehca_max_cq + 4 * ehca_max_qp;
 	/* create event queues */
-	ret = ehca_create_eq(shca, &shca->eq, EHCA_EQ, 2048);
+	ret = ehca_create_eq(shca, &shca->eq, EHCA_EQ, eq_size);
 	if (ret) {
 		ehca_err(&shca->ib_device, "Cannot create EQ.");
 		goto probe1;
diff --git a/drivers/infiniband/hw/ehca/ehca_qp.c b/drivers/infiniband/hw/ehca/ehca_qp.c
index 57bef11..18fba92 100644
--- a/drivers/infiniband/hw/ehca/ehca_qp.c
+++ b/drivers/infiniband/hw/ehca/ehca_qp.c
@@ -421,8 +421,18 @@ static struct ehca_qp *internal_create_qp(
 	u32 swqe_size = 0, rwqe_size = 0, ib_qp_num;
 	unsigned long flags;
 
-	if (init_attr->create_flags)
+	if (!atomic_add_unless(&shca->num_qps, 1, ehca_max_qp)) {
+		ehca_err(pd->device, "Unable to create QP, max number of %i "
+			 "QPs reached.", ehca_max_qp);
+		ehca_err(pd->device, "To increase the maximum number of QPs "
+			 "use the number_of_qps module parameter.\n");
+		return ERR_PTR(-ENOSPC);
+	}
+
+	if (init_attr->create_flags) {
+		atomic_dec(&shca->num_qps);
 		return ERR_PTR(-EINVAL);
+	}
 
 	memset(&parms, 0, sizeof(parms));
 	qp_type = init_attr->qp_type;
@@ -431,6 +441,7 @@ static struct ehca_qp *internal_create_qp(
 		init_attr->sq_sig_type != IB_SIGNAL_ALL_WR) {
 		ehca_err(pd->device, "init_attr->sg_sig_type=%x not allowed",
 			 init_attr->sq_sig_type);
+		atomic_dec(&shca->num_qps);
 		return ERR_PTR(-EINVAL);
 	}
 
@@ -455,6 +466,7 @@ static struct ehca_qp *internal_create_qp(
 
 	if (is_llqp && has_srq) {
 		ehca_err(pd->device, "LLQPs can't have an SRQ");
+		atomic_dec(&shca->num_qps);
 		return ERR_PTR(-EINVAL);
 	}
 
@@ -466,6 +478,7 @@ static struct ehca_qp *internal_create_qp(
 			ehca_err(pd->device, "no more than three SGEs "
 				 "supported for SRQ  pd=%p  max_sge=%x",
 				 pd, init_attr->cap.max_recv_sge);
+			atomic_dec(&shca->num_qps);
 			return ERR_PTR(-EINVAL);
 		}
 	}
@@ -477,6 +490,7 @@ static struct ehca_qp *internal_create_qp(
 	    qp_type != IB_QPT_SMI &&
 	    qp_type != IB_QPT_GSI) {
 		ehca_err(pd->device, "wrong QP Type=%x", qp_type);
+		atomic_dec(&shca->num_qps);
 		return ERR_PTR(-EINVAL);
 	}
 
@@ -490,6 +504,7 @@ static struct ehca_qp *internal_create_qp(
 					 "or max_rq_wr=%x for RC LLQP",
 					 init_attr->cap.max_send_wr,
 					 init_attr->cap.max_recv_wr);
+				atomic_dec(&shca->num_qps);
 				return ERR_PTR(-EINVAL);
 			}
 			break;
@@ -497,6 +512,7 @@ static struct ehca_qp *internal_create_qp(
 			if (!EHCA_BMASK_GET(HCA_CAP_UD_LL_QP, shca->hca_cap)) {
 				ehca_err(pd->device, "UD LLQP not supported "
 					 "by this adapter");
+				atomic_dec(&shca->num_qps);
 				return ERR_PTR(-ENOSYS);
 			}
 			if (!(init_attr->cap.max_send_sge <= 5
@@ -508,20 +524,22 @@ static struct ehca_qp *internal_create_qp(
 					 "or max_recv_sge=%x for UD LLQP",
 					 init_attr->cap.max_send_sge,
 					 init_attr->cap.max_recv_sge);
+				atomic_dec(&shca->num_qps);
 				return ERR_PTR(-EINVAL);
 			} else if (init_attr->cap.max_send_wr > 255) {
 				ehca_err(pd->device,
 					 "Invalid Number of "
 					 "max_send_wr=%x for UD QP_TYPE=%x",
 					 init_attr->cap.max_send_wr, qp_type);
+				atomic_dec(&shca->num_qps);
 				return ERR_PTR(-EINVAL);
 			}
 			break;
 		default:
 			ehca_err(pd->device, "unsupported LL QP Type=%x",
 				 qp_type);
+			atomic_dec(&shca->num_qps);
 			return ERR_PTR(-EINVAL);
-			break;
 		}
 	} else {
 		int max_sge = (qp_type == IB_QPT_UD || qp_type == IB_QPT_SMI
@@ -533,6 +551,7 @@ static struct ehca_qp *internal_create_qp(
 				 "send_sge=%x recv_sge=%x max_sge=%x",
 				 init_attr->cap.max_send_sge,
 				 init_attr->cap.max_recv_sge, max_sge);
+			atomic_dec(&shca->num_qps);
 			return ERR_PTR(-EINVAL);
 		}
 	}
@@ -543,6 +562,7 @@ static struct ehca_qp *internal_create_qp(
 	my_qp = kmem_cache_zalloc(qp_cache, GFP_KERNEL);
 	if (!my_qp) {
 		ehca_err(pd->device, "pd=%p not enough memory to alloc qp", pd);
+		atomic_dec(&shca->num_qps);
 		return ERR_PTR(-ENOMEM);
 	}
 
@@ -823,6 +843,7 @@ create_qp_exit1:
 
 create_qp_exit0:
 	kmem_cache_free(qp_cache, my_qp);
+	atomic_dec(&shca->num_qps);
 	return ERR_PTR(ret);
 }
 
@@ -1948,6 +1969,7 @@ static int internal_destroy_qp(struct ib_device *dev, struct ehca_qp *my_qp,
 	if (HAS_SQ(my_qp))
 		ipz_queue_dtor(my_pd, &my_qp->ipz_squeue);
 	kmem_cache_free(qp_cache, my_qp);
+	atomic_dec(&shca->num_qps);
 	return 0;
 }
 
-- 
1.5.5

^ permalink raw reply related

* Re: [REPOST][PATCH] IB/ehca: Allocate event queue size depending on max number of CQs and QPs
From: Roland Dreier @ 2008-04-29 18:20 UTC (permalink / raw)
  To: Stefan Roscher; +Cc: fenkes, LKML, OF-EWG, LinuxPPC-Dev, raisch, OF-General
In-Reply-To: <200804292015.38321.ossrosch@linux.vnet.ibm.com>

thanks, makes sense, applied.

fast turnaround too ;)

^ permalink raw reply

* SKB corruption on heavy traffic
From: Franca, Jose (NSN - PT/Portugal - MiniMD) @ 2008-04-29 18:39 UTC (permalink / raw)
  To: linuxppc-dev, linuxppc-embedded

[-- Attachment #1: Type: text/plain, Size: 29183 bytes --]

Hello Community!

	We are developing a MPC8247 based telecom board (512MB), using
linux 2.4 with some proprietary changes on IP stack and we are facing
some problems when we have heavy traffic on our Ethernet interfaces...
Namely:

		- When sending a ping flood we have skb corruption after
some variable time (looks like memory problems). Resuming what seems to
be happening: after release (dealloc) of the skb, the kernel tries to
access it again. To verify this we have implemented a list of "to be
freed" skb to have a delay between the time they are freed by the stack
and the actual dealloc. In this delay we are able to verify that the skb
is changed.  
		- We have reports of DMA transfers not completed in
heavy traffic.
		- After a while, and skb corrupted messages appearing in
the console, we start to have a scrambled characters. So, after some
seconds we don't understand what is written. This problem solves after
the crash or reboot. Which means that uart also seems to crack in heavy
load or at least some.


Below are some of our traces that show our problem... Someone has some
hints of what could be leading to this?? HHHHEEEEEELLLPP!!!!


Huge Thanks! 
Filipe.

F:bcmhal_shape_modid_phyport_to_pnum L:1046 Invalid modid received 48
port 3
Apr 25 19:59:14  system: F:bcmhal_shape_modid_phyport_to_pnum L:1046
Invalid modid received 48 port 3 
Apr 25 19:59:14  system: F:bcm_enet_rx L:1788 Packet received from an
invalid port 3 modid 48 
F:bcmhal_shape_modid_phyport_to_pnum L:1046 Invalid modid received 48
port 3
Apr 25 20:02:39  system: F:bcmhal_shape_modid_phyport_to_pnum L:1046
Invalid modid received 48 port 3 
Apr 25 20:02:39  system: F:bcm_enet_rx L:1788 Packet received from an
invalid port 3 modid 48 
F:bcmhal_shape_modid_phyport_to_pnum L:1046 Invalid modid received 48
port 3
Apr 25 20:06:57  system: F:bcmhal_shape_modid_phyport_to_pnum L:1046
Invalid modid received 48 port 3 
Apr 25 20:06:57  system: F:bcm_enet_rx L:1788 Packet received from an
invalid port 3 modid 48 
Apr 25 21:54:06  comd: buf = f5 43 7d 43 bb ff 80 18 36 70 6e 91 00 00
01 01 08 0a 00 0e c1 6d 00 00 41 15 6e 29 01 07 04 e6  
Apr 25 21:54:08  comd: buf = 00 00 00 00 00 00 00 00 00 00 00 00 43 49
47 47 07 05 20 71 00 00 00 00 00 00 00 00 00 00 00 03  
Apr 25 21:54:09  system:  skbuff.c:skb_clone:647: Bingle, got a freed
skb being cloned, return NULL!!!<1> skbuff.c:skb_clone:647: Bingle, got
a freed 
skb being cloned, return NULL!!!<3>tcp_write_xmit: clone failed ! 
Apr 25 21:54:09  comd: buf = 00 6e 29 01 07 04 e6 55 7b 00 00 ff ff 33
2d ff ff 00 00 00 0f 33 2d 00 03 00 00 00 08 00 00 00  
Apr 25 21:54:09  comd: buf = 00 00 00 00 00 00 00 00 00 00 00 00 53 49
44 41 2a 00 5a f9 00 00 00 00 00 00 00 00 00 00 00 01  
Apr 25 21:54:11  comd: message data field too long, max=12288  fd=82
((nil))       source: shelf=2021 slot=2223 service=2425 port=2627
destination: s
helf=1819 slot=1a1b service=1c1d port=1e1f message type: 28292a2b
length: 2c2d2e2f fd out of sync, will be closed (nil). 
Oops: Exception in kernel mode, sig: 7
NIP: C0034138 XER: 20000000 LR: C011B73C SP: C04E3D20 REGS: c04e3c70
TRAP: 0600    Not tainted
MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11
DAR: C1611DBF, DSISR: 00010920
TASK = c04e2000[2] 'keventd' Last syscall: 120 
last math cb0f8000 last altivec 00000000
GPR00: C1611DBF C04E3D20 C04E2000 C1611DAB 00000000 00000190 C1611DAB
0003CAEC 
GPR08: C0F98B04 D1C8201A C0F5C018 C0230000 22002024 1031E1BC 0FFD5000
1009B000 
GPR16: 00000000 00000000 00000000 00000000 003FF000 00000001 00000000
C01E0000 
GPR24: C01F0000 06D01B7F C04E3E18 00000001 C01D0000 0000158E 0000AC70
C3442DA0 
TESCR1 0xf0010040: 00100000 TESCR2 0xf0010044: 00000000
ESR 0xf0010884: 00000000 
PCI_EACR 0xf0010890: 0000000c 
PCI_EDCR 0xf0010898: 00000000 
PCI_ECCR 0xf00108a0: 00000000
GFPGA regs 
0xd0000000 1901200803051610 0000000000090101
0xd0000100 007f7f7f7f7f7f7f 7f7f7f7f7f7f7f7f
0xd0000200 008dd3d3d3d3d3d3 d3d3d3d3d3d3d3d3
0xd0000280 00ffffff00000000 d3d3d3d3d3d3d3d3
0xd0000300 ea19b993faff0040 0000050000001600
0xd0000380 000f0f0f00000000 0000000000000000
0xd0000400 660f01ff0100a5a5 a5a5a5a5a5a5a5a5
0xd0000480 0001010100000000 a5a5a5a5a5a5a5a5
0xd0000500 0f01010101010101 0101010101010101
0xd0000580 003f3f3f00000000 0101010101010101
0xd0000600 1f9a030a24440100 0000000000000000
0xd0000680 00ffffff00000000 0000000000000000
0xd0000690 00ffffff00000000 0000000000000000
0xd00006a0 00ffffff00000000 0000000000000000
0xd00006b0 00e727c000000000 0000000000000000
Call backtrace: 
C011D8CC C011B73C C011B7D0 C011B9C8 C011BC24 C01496CC C014A054 
C014D380 C0156584 C0156B70 C0137B08 C0137FD8 C0120B9C C0120C58 
C001B338 C002517C C000876C 
Apr 25 21:54:12  system:  skbuff.c:skb_clone:647: Bingle, got a freed
skb being cloned, return NULL!!!<1> skbuff.c:skb_clone:647: Bingle, got
a freed 
skb being cloned, return NULL!!!<1> skbuff.c:skb_clone:647: Bingle, got
a freed skb being cloned, return NULL!!!<1> skbuff.c:skb_clone:647:
Bingle, go
t a freed skb being cloned, return NULL!!!9C C0120C58  
Apr 25 21:54:12  system: C001B338 C002517C C000876C  
Apr 25 21:54:12  system: skb_release_data:400 memory ffffee84 out of
range! 
Apr 25 21:54:12  system: Call backtrace:  
Apr 25 21:54:12  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:12  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:12  system: C001B338 C002517C C000876C  
Apr 25 21:54:12  system: skb_release_data:400 memory ffffeea0 out of
range! 
Apr 25 21:54:12  system: Call backtrace:  
Apr 25 21:54:12  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:12  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:12  system: C001B338 C002517C C000876C  
Apr 25 21:54:12  system: skb_release_data:400 memory ffffeec4 out of
range! 
Apr 25 21:54:12  system: Call backtrace:  
Apr 25 21:54:12  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:12  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:12  system: C001B338 C002517C C000876C  
Apr 25 21:54:12  system: skb_release_data:400 memory ffffeef8 out of
range! 
Apr 25 21:54:12  system: Call backtrace:  
Apr 25 21:54:12  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:12  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:12  system: C001B338 C002517C C000876C  
Apr 25 21:54:12  system: skb_release_data:400 memory ffffef34 out of
range! 
Apr 25 21:54:12  system: Call backtrace:  
Apr 25 21:54:12  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:12  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:12  system: C001B338 C002517C C000876C  
Apr 25 21:54:12  system: skb_release_data:400 memory ffffef44 out of
range! 
Apr 25 21:54:12  system: Call backtrace:  
Apr 25 21:54:13  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:13  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:13  system: C001B338 C002517C C000876C  
Apr 25 21:54:13  system: skb_release_data:400 memory ffffef54 out of
range! 
Apr 25 21:54:13  system: Call backtrace:  
Apr 25 21:54:13  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:13  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:13  system: C001B338 C002517C C000876C  
Apr 25 21:54:13  system: skb_release_data:400 memory ffffef64 out of
range! 
Apr 25 21:54:13  system: Call backtrace:  
Apr 25 21:54:13  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:13  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:13  system: C001B338 C002517C C000876C  
Apr 25 21:54:13  system: skb_release_data:400 memory ffffef74 out of
range! 
Apr 25 21:54:13  system: Call backtrace:  
Apr 25 21:54:13  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:13  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:13  system: C001B338 C002517C C000876C  
Apr 25 21:54:13  system: skb_release_data:400 memory 41646472 out of
range! 
Apr 25 21:54:13  system: Call backtrace:  
Apr 25 21:54:13  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:13  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
linux-bcm-core (127): soc_counter_thread: DMA did not finish
buf32=cd380000
linux-bcm-core (132): soc_counter_thread: DMA did not finish
buf32=cd389800
linux-bcm-core (130): soc_counter_thread: DMA did not finish
buf32=cd382400
Apr 25 21:54:13  system: C001B338 C002517C C000876C  
Apr 25 21:54:13  system: skb_release_data:400 memory 700a0000 out of
range! 
Apr 25 21:54:13  system: Call backtrace:  
Apr 25 21:54:13  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:13  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:13  system: C001B338 C002517C C000876C  
Apr 25 21:54:13  system: skb_release_data:400 memory 6d654164 out of
range! 
Apr 25 21:54:13  system: Call backtrace:  
Apr 25 21:54:13  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:13  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:13  system: C001B338 C002517C C000876C  
Apr 25 21:54:13  system: skb_release_data:400 memory 2025700a out of
range! 
Apr 25 21:54:13  system: Call backtrace:  
Apr 25 21:54:13  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:13  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:13  system: C001B338 C002517C C000876C  
Apr 25 21:54:13  system: skb_release_data:400 memory 496e2025 out of
range! 
Apr 25 21:54:13  system: Call backtrace:  
Apr 25 21:54:13  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:13  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:13  system: C001B338 C002517C C000876C  
Apr 25 21:54:13  system: skb_release_data:400 memory 70293a0a out of
range! 
Apr 25 21:54:13  system: Call backtrace:  
Apr 25 21:54:13  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:13  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:13  system: C001B338 C002517C C000876C  
Apr 25 21:54:13  system: skb_release_data:400 memory 726f6c42 out of
range! 
Apr 25 21:54:13  system: Call backtrace:  
Apr 25 21:54:14  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:14  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:14  system: C001B338 C002517C C000876C  
Apr 25 21:54:14  system: skb_release_data:400 memory 72616365 out of
range! 
Apr 25 21:54:14  system: Call backtrace:  
Apr 25 21:54:14  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:14  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:14  system: C001B338 C002517C C000876C  
Apr 25 21:54:14  system: skb_release_data:400 memory 31000000 out of
range! 
Apr 25 21:54:14  system: Call backtrace:  
Apr 25 21:54:14  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:14  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:14  system: C001B338 C002517C C000876C  
Apr 25 21:54:14  system: skb_release_data:400 memory 73202825 out of
range! 
Apr 25 21:54:14  system: Call backtrace:  
Apr 25 21:54:14  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:14  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:14  system: C001B338 C002517C C000876C  
Apr 25 21:54:14  system: skb_release_data:400 memory 70526574 out of
range! 
Apr 25 21:54:14  system: Call backtrace:  
Apr 25 21:54:14  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:14  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:14  system: C001B338 C002517C C000876C  
Apr 25 21:54:14  system: skb_release_data:400 memory 203d2025 out of
range! 
Apr 25 21:54:14  system: Call backtrace:  
Apr 25 21:54:14  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:14  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:14  system: C001B338 C002517C C000876C  
Apr 25 21:54:14  system: skb_release_data:400 memory 726f6c42 out of
range! 
Apr 25 21:54:14  system: Call backtrace:  
Apr 25 21:54:14  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:14  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:14  system: C001B338 C002517C C000876C  
Apr 25 21:54:14  system: skb_release_data:400 memory 72616365 out of
range! 
Apr 25 21:54:14  system: Call backtrace:  
Apr 25 21:54:14  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:14  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:14  system: C001B338 C002517C C000876C  
Apr 25 21:54:14  system: skb_release_data:400 memory 32000000 out of
range! 
Apr 25 21:54:14  system: Call backtrace:  
Apr 25 21:54:14  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:14  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:14  system: C001B338 C002517C C000876C  
Apr 25 21:54:14  system: skb_release_data:400 memory 61636b74 out of
range! 
Apr 25 21:54:14  system: Call backtrace:  
Apr 25 21:54:14  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:14  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:14  system: C001B338 C002517C C000876C  
Apr 25 21:54:14  system: skb_release_data:400 memory 54657374 out of
range! 
Apr 25 21:54:14  system: Call backtrace:  
Apr 25 21:54:14  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:14  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:14  system: C001B338 C002517C C000876C  
Apr 25 21:54:15  system: skb_release_data:400 memory 68756875 out of
range! 
Apr 25 21:54:15  system: Call backtrace:  
Apr 25 21:54:15  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:15  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:15  system: C001B338 C002517C C000876C  
Apr 25 21:54:15  system: skb_release_data:400 memory 10015ddc out of
range! 
Apr 25 21:54:15  system: Call backtrace:  
Apr 25 21:54:15  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:15  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:15  system: C001B338 C002517C C000876C  
Apr 25 21:54:15  system: skb_release_data:400 memory 0000ffff out of
range! 
Apr 25 21:54:15  system: Call backtrace:  
Apr 25 21:54:15  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:15  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:15  system: C001B338 C002517C C000876C  
Apr 25 21:54:15  system: skb_release_data:400 memory 64437472 out of
range! 
Apr 25 21:54:15  system: Call backtrace:  
Apr 25 21:54:15  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:15  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:15  system: C001B338 C002517C C000876C  
Apr 25 21:54:15  system: skb_release_data:400 memory 636b0000 out of
range! 
Apr 25 21:54:15  system: Call backtrace:  
Apr 25 21:54:15  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:15  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
linux-bcm-core (127): soc_counter_thread: DMA did not finish
buf32=cd380000
linux-bcm-core (132): soc_counter_thread: DMA did not finish
buf32=cd389800
linux-bcm-core (130): soc_counter_thread: DMA did not finish
buf32=cd382400
Apr 25 21:54:15  system: C001B338 C002517C C000876C  
Apr 25 21:54:15  system: skb_release_data:400 memory 014a5374 out of
range! 
Apr 25 21:54:15  system: Call backtrace:  
Apr 25 21:54:15  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:15  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:15  system: C001B338 C002517C C000876C  
Apr 25 21:54:15  system: skb_release_data:400 memory 7053796e out of
range! 
Apr 25 21:54:15  system: Call backtrace:  
Apr 25 21:54:15  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:15  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:15  system: C001B338 C002517C C000876C  
Apr 25 21:54:15  system: skb_release_data:400 memory ee0e612c out of
range! 
Apr 25 21:54:15  system: Call backtrace:  
Apr 25 21:54:15  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:15  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:15  system: C001B338 C002517C C000876C  
Apr 25 21:54:15  system: skb_release_data:400 memory 076dc419 out of
range! 
Apr 25 21:54:15  system: Call backtrace:  
Apr 25 21:54:15  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:15  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:15  system: C001B338 C002517C C000876C  
Apr 25 21:54:15  system: skb_release_data:400 memory e963a535 out of
range! 
Apr 25 21:54:15  system: Call backtrace:  
Apr 25 21:54:15  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:15  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:15  system: C001B338 C002517C C000876C  
Apr 25 21:54:16  system: skb_release_data:400 memory 0edb8832 out of
range! 
Apr 25 21:54:16  system: Call backtrace:  
Apr 25 21:54:16  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:16  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:16  system: C001B338 C002517C C000876C  
Apr 25 21:54:16  system: skb_release_data:400 memory e0d5e91e out of
range! 
Apr 25 21:54:16  system: Call backtrace:  
Apr 25 21:54:16  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:16  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:16  system: C001B338 C002517C C000876C  
Apr 25 21:54:16  system: skb_release_data:400 memory 09b64c2b out of
range! 
Apr 25 21:54:16  system: Call backtrace:  
Apr 25 21:54:16  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:16  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:16  system: C001B338 C002517C C000876C  
Apr 25 21:54:16  system: skb_release_data:400 memory e7b82d07 out of
range! 
Apr 25 21:54:16  system: Call backtrace:  
Apr 25 21:54:16  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:16  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:16  system: C001B338 C002517C C000876C  
Apr 25 21:54:16  system: skb_release_data:400 memory 1db71064 out of
range! 
Apr 25 21:54:16  system: Call backtrace:  
Apr 25 21:54:16  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:16  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:16  system: C001B338 C002517C C000876C  
Apr 25 21:54:16  system: skb_release_data:400 memory f3b97148 out of
range! 
Apr 25 21:54:16  system: Call backtrace:  
Apr 25 21:54:16  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:16  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:16  system: C001B338 C002517C C000876C  
Apr 25 21:54:16  system: skb_release_data:400 memory 1adad47d out of
range! 
Apr 25 21:54:16  system: Call backtrace:  
Apr 25 21:54:16  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:16  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:16  system: C001B338 C002517C C000876C  
Apr 25 21:54:16  system: skb_release_data:400 memory f4d4b551 out of
range! 
Apr 25 21:54:16  system: Call backtrace:  
Apr 25 21:54:16  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:16  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:16  system: C001B338 C002517C C000876C  
Apr 25 21:54:16  system: skb_release_data:400 memory 136c9856 out of
range! 
Apr 25 21:54:16  system: Call backtrace:  
Apr 25 21:54:16  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:16  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:16  system: C001B338 C002517C C000876C  
Apr 25 21:54:16  system: skb_release_data:400 memory fd62f97a out of
range! 
Apr 25 21:54:16  system: Call backtrace:  
Apr 25 21:54:16  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:16  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:16  system: C001B338 C002517C C000876C  
Apr 25 21:54:16  system: skb_release_data:400 memory 14015c4f out of
range! 
Apr 25 21:54:16  system: Call backtrace:  
Apr 25 21:54:16  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:16  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:17  system: C001B338 C002517C C000876C  
Apr 25 21:54:17  system: skb_release_data:400 memory fa0f3d63 out of
range! 
Apr 25 21:54:17  system: Call backtrace:  
Apr 25 21:54:17  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:17  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:17  system: C001B338 C002517C C000876C  
Apr 25 21:54:17  system: skb_release_data:400 memory 3b6e20c8 out of
range! 
Apr 25 21:54:17  system: Call backtrace:  
Apr 25 21:54:17  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:17  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:17  system: C001B338 C002517C C000876C  
Apr 25 21:54:17  system: skb_release_data:400 memory d56041e4 out of
range! 
Apr 25 21:54:17  system: Call backtrace:  
Apr 25 21:54:17  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:17  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:17  system: C001B338 C002517C C000876C  
Apr 25 21:54:17  system: skb_release_data:400 memory 3c03e4d1 out of
range! 
Apr 25 21:54:17  system: Call backtrace:  
Apr 25 21:54:17  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:17  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:17  system: C001B338 C002517C C000876C  
Apr 25 21:54:17  system: skb_release_data:400 memory d20d85fd out of
range! 
Apr 25 21:54:17  system: Call backtrace:  
Apr 25 21:54:17  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:17  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
linux-bcm-core (127): soc_counter_thread: DMA did not finish
buf32=cd380000
linux-bcm-core (132): soc_counter_thread: DMA did not finish
buf32=cd389800
linux-bcm-core (130): soc_counter_thread: DMA did not finish
buf32=cd382400
Apr 25 21:54:17  system: C001B338 C002517C C000876C  
Apr 25 21:54:17  system: skb_release_data:400 memory 35b5a8fa out of
range! 
Apr 25 21:54:17  system: Call backtrace:  
Apr 25 21:54:17  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:17  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:17  system: C001B338 C002517C C000876C  
Apr 25 21:54:17  system: skb_release_data:400 memory dbbbc9d6 out of
range! 
Apr 25 21:54:17  system: Call backtrace:  
Apr 25 21:54:17  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:17  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:17  system: C001B338 C002517C C000876C  
Apr 25 21:54:17  system: skb_release_data:400 memory 32d86ce3 out of
range! 
Apr 25 21:54:17  system: Call backtrace:  
Apr 25 21:54:17  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:17  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:17  system: C001B338 C002517C C000876C  
Apr 25 21:54:17  system: skb_release_data:400 memory dcd60dcf out of
range! 
Apr 25 21:54:17  system: Call backtrace:  
Apr 25 21:54:17  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:17  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:17  system: C001B338 C002517C C000876C  
Apr 25 21:54:17  system: skb_release_data:400 memory 26d930ac out of
range! 
Apr 25 21:54:17  system: Call backtrace:  
Apr 25 21:54:17  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:17  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:18  system: C001B338 C002517C C000876C  
Apr 25 21:54:18  system: skb_release_data:400 memory 21b4f4b5 out of
range! 
Apr 25 21:54:18  system: Call backtrace:  
Apr 25 21:54:18  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:18  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:18  system: C001B338 C002517C C000876C  
Apr 25 21:54:18  system: skb_release_data:400 memory cfba9599 out of
range! 
Apr 25 21:54:18  system: Call backtrace:  
Apr 25 21:54:18  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:18  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:18  system: C001B338 C002517C C000876C  
Apr 25 21:54:18  system: skb_release_data:400 memory 2802b89e out of
range! 
Apr 25 21:54:18  system: Call backtrace:  
Apr 25 21:54:18  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:18  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:18  system: C001B338 C002517C C000876C  
Apr 25 21:54:18  system: skb_release_data:400 memory 2f6f7c87 out of
range! 
Apr 25 21:54:18  system: Call backtrace:  
Apr 25 21:54:18  system: C011D8CC C011B720 C011B7D0 C011B9C8 C011BC24
C01496CC C014A054  
Apr 25 21:54:18  system: C014D380 C0156584 C0156B70 C0137B08 C0137FD8
C0120B9C C0120C58  
Apr 25 21:54:18  system: C001B338 C002517C C000876C  
Apr 25 21:54:18  system: Oops: Exception in kernel mode, sig: 7 
Apr 25 21:54:18  system: NIP: C0034138 XER: 20000000 LR: C011B73C SP:
C04E3D20 REGS: c04e3c70 TRAP: 0600    Not tainted 
Apr 25 21:54:18  system: MSR: 00009032 EE: 1 PR: 0 FP: 0 ME: 1 IR/DR: 11

Apr 25 21:54:18  system: DAR: C1611DBF, DSISR: 00010920 
Apr 25 21:54:18  system: TASK = c04e2000[2] 'keventd' Last syscall: 120

Apr 25 21:54:18  system: last math cb0f8000 last altivec 00000000 
Apr 25 21:54:18  system: GPR00: C1611DBF C04E3D20 C04E2000 C1611DAB
00000000 00000190 C1611DAB 0003CAEC  
Apr 25 21:54:18  system: GPR08: C0F98B04 D1C8201A C0F5C018 C0230000
22002024 1031E1BC 0FFD5000 1009B000  
Apr 25 21:54:18  system: GPR16: 00000000 00000000 00000000 00000000
003FF000 00000001 00000000 C01E0000  
Apr 25 21:54:18  system: GPR24: C01F0000 06D01B7F C04E3E18 00000001
C01D0000 0000158E 0000AC70 C3442DA0  
Apr 25 21:54:18  system: TESCR1 0xf0010040: 00100000 TESCR2 0xf0010044:
00000000 
Apr 25 21:54:18  system: ESR 0xf0010884: 00000000  
Apr 25 21:54:18  system: PCI_EACR 0xf0010890: 0000000c  
Apr 25 21:54:18  system: PCI_EDCR 0xf0010898: 00000000  
Apr 25 21:54:18  system: PCI_ECCR 0xf00108a0: 00000000 



[-- Attachment #2: Type: text/html, Size: 48110 bytes --]

^ permalink raw reply


This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox