* [PATCH 2/2] powerpc: Optimise enable_kernel_altivec
From: Anton Blanchard @ 2012-04-16 6:56 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
In-Reply-To: <20120416165459.6da18f9c@kryten>
Add two optimisations to enable_kernel_altivec:
- enable_kernel_altivec has already determined if we need to
save the previous task's state but we call giveup_altivec
in both cases, requiring an extra branch in giveup_altivec. Create
giveup_altivec_notask which only turns on the VMX bit in the
MSR.
- We write the VMX MSR bit each time we call enable_kernel_altivec
even it was already set. Check the bit and branch out if we have
already set it. The classic case for this is vectored IO
where we have to copy multiple buffers to or from userspace.
The following testcase was used to confirm this patch improves
performance:
http://ozlabs.org/~anton/junkcode/copy_to_user.c
Since the current breakpoint for using VMX in copy_tofrom_user is
4096 bytes, I'm using buffers of 4096 + 1 cacheline (4224) bytes.
A benchmark of 16 entry readvs (-s 16):
time copy_to_user -l 4224 -s 16 -i 1000000
completes 5.2% faster on a POWER7 PS700.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/kernel/process.c
===================================================================
--- linux-build.orig/arch/powerpc/kernel/process.c 2012-04-16 11:35:19.000000000 +1000
+++ linux-build/arch/powerpc/kernel/process.c 2012-04-16 12:56:47.489355793 +1000
@@ -124,7 +124,7 @@ void enable_kernel_altivec(void)
if (current->thread.regs && (current->thread.regs->msr & MSR_VEC))
giveup_altivec(current);
else
- giveup_altivec(NULL); /* just enable AltiVec for kernel - force */
+ giveup_altivec_notask();
#else
giveup_altivec(last_task_used_altivec);
#endif /* CONFIG_SMP */
Index: linux-build/arch/powerpc/kernel/vector.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/vector.S 2012-04-12 20:06:21.000000000 +1000
+++ linux-build/arch/powerpc/kernel/vector.S 2012-04-16 12:56:47.489355793 +1000
@@ -89,6 +89,16 @@ _GLOBAL(load_up_altivec)
/* restore registers and return */
blr
+_GLOBAL(giveup_altivec_notask)
+ mfmsr r3
+ andis. r4,r3,MSR_VEC@h
+ bnelr /* Already enabled? */
+ oris r3,r3,MSR_VEC@h
+ SYNC
+ MTMSRD(r3) /* enable use of VMX now */
+ isync
+ blr
+
/*
* giveup_altivec(tsk)
* Disable VMX for the task given as the argument,
Index: linux-build/arch/powerpc/include/asm/switch_to.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/switch_to.h 2012-04-16 12:56:45.149313158 +1000
+++ linux-build/arch/powerpc/include/asm/switch_to.h 2012-04-16 12:56:47.489355793 +1000
@@ -40,6 +40,7 @@ static inline void discard_lazy_cpu_stat
#ifdef CONFIG_ALTIVEC
extern void flush_altivec_to_thread(struct task_struct *);
extern void giveup_altivec(struct task_struct *);
+extern void giveup_altivec_notask(void);
#else
static inline void flush_altivec_to_thread(struct task_struct *t)
{
^ permalink raw reply
* [PATCH 1/2] powerpc: Remove empty giveup_altivec function on book3e CPUs
From: Anton Blanchard @ 2012-04-16 6:54 UTC (permalink / raw)
To: benh, paulus; +Cc: linuxppc-dev
Use an empty inline instead of an empty function to implement
giveup_altivec on book3e CPUs, similar to flush_altivec_to_thread.
Signed-off-by: Anton Blanchard <anton@samba.org>
---
Index: linux-build/arch/powerpc/include/asm/switch_to.h
===================================================================
--- linux-build.orig/arch/powerpc/include/asm/switch_to.h 2012-04-16 12:56:11.000000000 +1000
+++ linux-build/arch/powerpc/include/asm/switch_to.h 2012-04-16 12:56:45.149313158 +1000
@@ -21,7 +21,6 @@ extern void disable_kernel_fp(void);
extern void enable_kernel_fp(void);
extern void flush_fp_to_thread(struct task_struct *);
extern void enable_kernel_altivec(void);
-extern void giveup_altivec(struct task_struct *);
extern void load_up_altivec(struct task_struct *);
extern int emulate_altivec(struct pt_regs *);
extern void __giveup_vsx(struct task_struct *);
@@ -40,10 +39,14 @@ static inline void discard_lazy_cpu_stat
#ifdef CONFIG_ALTIVEC
extern void flush_altivec_to_thread(struct task_struct *);
+extern void giveup_altivec(struct task_struct *);
#else
static inline void flush_altivec_to_thread(struct task_struct *t)
{
}
+static inline void giveup_altivec(struct task_struct *t)
+{
+}
#endif
#ifdef CONFIG_VSX
Index: linux-build/arch/powerpc/kernel/head_44x.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/head_44x.S 2012-04-16 12:56:11.976708702 +1000
+++ linux-build/arch/powerpc/kernel/head_44x.S 2012-04-16 12:56:45.153313231 +1000
@@ -778,14 +778,6 @@ _GLOBAL(__fixup_440A_mcheck)
blr
/*
- * extern void giveup_altivec(struct task_struct *prev)
- *
- * The 44x core does not have an AltiVec unit.
- */
-_GLOBAL(giveup_altivec)
- blr
-
-/*
* extern void giveup_fpu(struct task_struct *prev)
*
* The 44x core does not have an FPU.
Index: linux-build/arch/powerpc/kernel/head_fsl_booke.S
===================================================================
--- linux-build.orig/arch/powerpc/kernel/head_fsl_booke.S 2012-04-16 12:56:11.940708046 +1000
+++ linux-build/arch/powerpc/kernel/head_fsl_booke.S 2012-04-16 12:56:45.153313231 +1000
@@ -874,14 +874,6 @@ _GLOBAL(__setup_e500mc_ivors)
sync
blr
-/*
- * extern void giveup_altivec(struct task_struct *prev)
- *
- * The e500 core does not have an AltiVec unit.
- */
-_GLOBAL(giveup_altivec)
- blr
-
#ifdef CONFIG_SPE
/*
* extern void giveup_spe(struct task_struct *prev)
^ permalink raw reply
* [PATCH] powerpc: fix system.h fallout in sysdev/scom.c [chroma_defconfig]
From: Paul Gortmaker @ 2012-04-16 5:04 UTC (permalink / raw)
To: benh; +Cc: David Howells, Paul Gortmaker, linuxppc-dev
The following shows up in chroma_defconfig:
CC arch/powerpc/sysdev/scom.o
arch/powerpc/sysdev/scom.c: In function 'scom_debug_init':
arch/powerpc/sysdev/scom.c:182:36: error: 'powerpc_debugfs_root' undeclared (first use in this function)
arch/powerpc/sysdev/scom.c:182:36: note: each undeclared identifier is reported only once for each function it appears in
make[2]: *** [arch/powerpc/sysdev/scom.o] Error 1
make[1]: *** [arch/powerpc/sysdev/scom.o] Error 2
A bisect leads to commit 9ffc93f203c18a70623f21950f1dd473c9ec48cd
"Remove all #inclusions of asm/system.h"
Add the debug header which contains powerpc_debugfs_root.
Cc: David Howells <dhowells@redhat.com>
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
---
[Ben, let me know if you want to take this or have me keep it.]
diff --git a/arch/powerpc/sysdev/scom.c b/arch/powerpc/sysdev/scom.c
index 49a3ece..702256a 100644
--- a/arch/powerpc/sysdev/scom.c
+++ b/arch/powerpc/sysdev/scom.c
@@ -22,6 +22,7 @@
#include <linux/debugfs.h>
#include <linux/slab.h>
#include <linux/export.h>
+#include <asm/debug.h>
#include <asm/prom.h>
#include <asm/scom.h>
--
1.7.9.1
^ permalink raw reply related
* PPC / USB: kernel hangs in warm boot on 8513 in fsl-ehci
From: Anthony Foiani @ 2012-04-16 4:45 UTC (permalink / raw)
To: linux-usb, linuxppc-dev
Greetings.
I'm working on an embedded board using the MPC8315E processor. After
many (10-20+) warm boots, the kernel boot sequence will eventually
hang here:
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
/immr@e0000000/usb@23000: Invalid 'dr_mode' property, fallback to host mode
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
On a normal boot, it continues with the irq/iomem message:
ehci_hcd: USB 2.0 'Enhanced' Host Controller (EHCI) Driver
/immr@e0000000/usb@23000: Invalid 'dr_mode' property, fallback to host mode
fsl-ehci fsl-ehci.0: Freescale On-Chip EHCI Host Controller
fsl-ehci fsl-ehci.0: new USB bus registered, assigned bus number 1
fsl-ehci fsl-ehci.0: irq 38, io mem 0xe0023000
fsl-ehci fsl-ehci.0: USB 2.0 started, EHCI 1.00
I found a recent conversation about a similar hang on the 5020,
including one patch that had made it into -stable, along with a few
other patches that didn't but maybe should; please see my exchange
with Greg KH here:
https://lkml.org/lkml/2012/4/13/10
I did apply the most obvious set of patches to my kernel, but I'm
still seeing hangs. I'm using 3.0.6 with vendor patches and a few
other odds and ends applied. The only relevant change to fsl-ehci is
the one inspired by the patches mentioned in the above message:
------------------------------------------------------------------------
diff --git a/drivers/usb/host/ehci-fsl.c b/drivers/usb/host/ehci-fsl.c
index f380bf9..ac4ca27 100644
--- a/drivers/usb/host/ehci-fsl.c
+++ b/drivers/usb/host/ehci-fsl.c
@@ -217,6 +217,9 @@ static void ehci_fsl_setup_phy(struct ehci_hcd *ehci,
{
u32 portsc;
+ struct usb_hcd *hcd = ehci_to_hcd(ehci);
+ void __iomem *non_ehci = hcd->regs;
+
portsc = ehci_readl(ehci, &ehci->regs->port_status[port_offset]);
portsc &= ~(PORT_PTS_MSK | PORT_PTS_PTW);
@@ -231,6 +234,9 @@ static void ehci_fsl_setup_phy(struct ehci_hcd *ehci,
portsc |= PORT_PTS_PTW;
/* fall through */
case FSL_USB2_PHY_UTMI:
+ /* enable UTMI PHY */
+ setbits32(non_ehci + FSL_SOC_USB_CTRL, CTRL_UTMI_PHY_EN);
+ msleep(10);
portsc |= PORT_PTS_UTMI;
break;
case FSL_USB2_PHY_NONE:
@@ -252,21 +258,18 @@ static void ehci_fsl_usb_setup(struct ehci_hcd *ehci)
if (pdata->have_sysif_regs) {
temp = in_be32(non_ehci + FSL_SOC_USB_CTRL);
out_be32(non_ehci + FSL_SOC_USB_CTRL, temp | 0x00000004);
- out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0000001b);
- }
-#if defined(CONFIG_PPC32) && !defined(CONFIG_NOT_COHERENT_CACHE)
- /*
- * Turn on cache snooping hardware, since some PowerPC platforms
- * wholly rely on hardware to deal with cache coherent
- */
+ /*
+ * Turn on cache snooping hardware, since some PowerPC platforms
+ * wholly rely on hardware to deal with cache coherent
+ */
- /* Setup Snooping for all the 4GB space */
- /* SNOOP1 starts from 0x0, size 2G */
- out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
- /* SNOOP2 starts from 0x80000000, size 2G */
- out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
-#endif
+ /* Setup Snooping for all the 4GB space */
+ /* SNOOP1 starts from 0x0, size 2G */
+ out_be32(non_ehci + FSL_SOC_USB_SNOOP1, 0x0 | SNOOP_SIZE_2GB);
+ /* SNOOP2 starts from 0x80000000, size 2G */
+ out_be32(non_ehci + FSL_SOC_USB_SNOOP2, 0x80000000 | SNOOP_SIZE_2GB);
+ }
if ((pdata->operating_mode == FSL_USB2_DR_HOST) ||
(pdata->operating_mode == FSL_USB2_DR_OTG))
diff --git a/drivers/usb/host/ehci-fsl.h b/drivers/usb/host/ehci-fsl.h
index 4918062..16665a4 100644
--- a/drivers/usb/host/ehci-fsl.h
+++ b/drivers/usb/host/ehci-fsl.h
@@ -45,5 +45,6 @@
#define FSL_SOC_USB_PRICTRL 0x40c /* NOTE: big-endian */
#define FSL_SOC_USB_SICTRL 0x410 /* NOTE: big-endian */
#define FSL_SOC_USB_CTRL 0x500 /* NOTE: big-endian */
+#define CTRL_UTMI_PHY_EN (1 << 9)
#define SNOOP_SIZE_2GB 0x1e
#endif /* _EHCI_FSL_H */
------------------------------------------------------------------------
But I'm still seeing the hang. (And I realize, now that I'm not head
down on the project, that the snooping fixes are probably irrelevant
for a single-core system like mine.)
Does anyone have suggestions on where I can go from here?
I could try the latest kernels, but due to our vendor not upstreaming
their patches, there could be some pain in that transition.
Thanks in advance for any suggestions.
Best regards,
Anthony Foiani
^ permalink raw reply related
* [PATCH 4/4] powerpc/mpc85xx: add MPIC message dts node
From: Mingkai Hu @ 2012-04-16 2:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mingkai Hu
In-Reply-To: <1334541908-19331-3-git-send-email-Mingkai.hu@freescale.com>
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi | 43 +++++++++++++++++++++
arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi | 10 +++++
2 files changed, 53 insertions(+), 0 deletions(-)
create mode 100644 arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi
diff --git a/arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi b/arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi
new file mode 100644
index 0000000..1cf0b77
--- /dev/null
+++ b/arch/powerpc/boot/dts/fsl/pq3-mpic-message-B.dtsi
@@ -0,0 +1,43 @@
+/*
+ * PQ3 MPIC Message (Group B) device tree stub [ controller @ offset 0x42400 ]
+ *
+ * Copyright 2012 Freescale Semiconductor Inc.
+ *
+ * Redistribution and use in source and binary forms, with or without
+ * modification, are permitted provided that the following conditions are met:
+ * * Redistributions of source code must retain the above copyright
+ * notice, this list of conditions and the following disclaimer.
+ * * Redistributions in binary form must reproduce the above copyright
+ * notice, this list of conditions and the following disclaimer in the
+ * documentation and/or other materials provided with the distribution.
+ * * Neither the name of Freescale Semiconductor nor the
+ * names of its contributors may be used to endorse or promote products
+ * derived from this software without specific prior written permission.
+ *
+ *
+ * ALTERNATIVELY, this software may be distributed under the terms of the
+ * GNU General Public License ("GPL") as published by the Free Software
+ * Foundation, either version 2 of that License or (at your option) any
+ * later version.
+ *
+ * THIS SOFTWARE IS PROVIDED BY Freescale Semiconductor ``AS IS'' AND ANY
+ * EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
+ * WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE
+ * DISCLAIMED. IN NO EVENT SHALL Freescale Semiconductor BE LIABLE FOR ANY
+ * DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES
+ * (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
+ * LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND
+ * ON ANY THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
+ * (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS
+ * SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
+ */
+
+message@42400 {
+ compatible = "fsl,mpic-v3.1-msgr";
+ reg = <0x42400 0x200>;
+ interrupts = <
+ 0xb4 2 0 0
+ 0xb5 2 0 0
+ 0xb6 2 0 0
+ 0xb7 2 0 0>;
+};
diff --git a/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi b/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
index fdedf7b..71c30eb 100644
--- a/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
+++ b/arch/powerpc/boot/dts/fsl/pq3-mpic.dtsi
@@ -53,6 +53,16 @@ timer@41100 {
3 0 3 0>;
};
+message@41400 {
+ compatible = "fsl,mpic-v3.1-msgr";
+ reg = <0x41400 0x200>;
+ interrupts = <
+ 0xb0 2 0 0
+ 0xb1 2 0 0
+ 0xb2 2 0 0
+ 0xb3 2 0 0>;
+};
+
msi@41600 {
compatible = "fsl,mpic-msi";
reg = <0x41600 0x80>;
--
1.7.5.1
^ permalink raw reply related
* [PATCH 3/4] powerpc/mpic_msgr: fix offset error when setting mer register
From: Mingkai Hu @ 2012-04-16 2:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mingkai Hu
In-Reply-To: <1334541908-19331-2-git-send-email-Mingkai.hu@freescale.com>
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
arch/powerpc/sysdev/mpic_msgr.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
index dc1cfe3..483d8fa 100644
--- a/arch/powerpc/sysdev/mpic_msgr.c
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -228,7 +228,7 @@ static __devinit int mpic_msgr_probe(struct platform_device *dev)
reg_number = block_number * MPIC_MSGR_REGISTERS_PER_BLOCK + i;
msgr->base = msgr_block_addr + i * MPIC_MSGR_STRIDE;
- msgr->mer = msgr->base + MPIC_MSGR_MER_OFFSET;
+ msgr->mer = (u32 *)((u8 *)msgr->base + MPIC_MSGR_MER_OFFSET);
msgr->in_use = MSGR_FREE;
msgr->num = i;
raw_spin_lock_init(&msgr->lock);
--
1.7.5.1
^ permalink raw reply related
* [PATCH 2/4] powerpc/mpic_msgr: add lock for MPIC message global variable
From: Mingkai Hu @ 2012-04-16 2:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mingkai Hu
In-Reply-To: <1334541908-19331-1-git-send-email-Mingkai.hu@freescale.com>
Also fix issue of accessing invalid msgr pointer issue. The local
msgr pointer in fucntion mpic_msgr_get will be accessed before
getting a valid address which will cause kernel crash.
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
arch/powerpc/sysdev/mpic_msgr.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/arch/powerpc/sysdev/mpic_msgr.c b/arch/powerpc/sysdev/mpic_msgr.c
index 6e7fa38..dc1cfe3 100644
--- a/arch/powerpc/sysdev/mpic_msgr.c
+++ b/arch/powerpc/sysdev/mpic_msgr.c
@@ -27,6 +27,7 @@
static struct mpic_msgr **mpic_msgrs;
static unsigned int mpic_msgr_count;
+static DEFINE_RAW_SPINLOCK(msgrs_lock);
static inline void _mpic_msgr_mer_write(struct mpic_msgr *msgr, u32 value)
{
@@ -56,12 +57,11 @@ struct mpic_msgr *mpic_msgr_get(unsigned int reg_num)
if (reg_num >= mpic_msgr_count)
return ERR_PTR(-ENODEV);
- raw_spin_lock_irqsave(&msgr->lock, flags);
- if (mpic_msgrs[reg_num]->in_use == MSGR_FREE) {
- msgr = mpic_msgrs[reg_num];
+ raw_spin_lock_irqsave(&msgrs_lock, flags);
+ msgr = mpic_msgrs[reg_num];
+ if (msgr->in_use == MSGR_FREE)
msgr->in_use = MSGR_INUSE;
- }
- raw_spin_unlock_irqrestore(&msgr->lock, flags);
+ raw_spin_unlock_irqrestore(&msgrs_lock, flags);
return msgr;
}
--
1.7.5.1
^ permalink raw reply related
* [PATCH 1/4] powerpc/mpic_msgr: fix compile error when SMP disabled
From: Mingkai Hu @ 2012-04-16 2:05 UTC (permalink / raw)
To: linuxppc-dev; +Cc: Mingkai Hu
In file included from arch/powerpc/sysdev/mpic_msgr.c:20:0:
~/arch/powerpc/include/asm/mpic_msgr.h: In function 'mpic_msgr_set_destination':
~/arch/powerpc/include/asm/mpic_msgr.h:117:2:
error: implicit declaration of function 'get_hard_smp_processor_id'
make[1]: *** [arch/powerpc/sysdev/mpic_msgr.o] Error 1
Signed-off-by: Mingkai Hu <Mingkai.hu@freescale.com>
---
arch/powerpc/include/asm/mpic_msgr.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/include/asm/mpic_msgr.h b/arch/powerpc/include/asm/mpic_msgr.h
index 3ec37dc..326d33c 100644
--- a/arch/powerpc/include/asm/mpic_msgr.h
+++ b/arch/powerpc/include/asm/mpic_msgr.h
@@ -13,6 +13,7 @@
#include <linux/types.h>
#include <linux/spinlock.h>
+#include <asm/smp.h>
struct mpic_msgr {
u32 __iomem *base;
--
1.7.5.1
^ permalink raw reply related
* [PATCH] powerpc/fsl: Distribute interrupts on all CPUs by default
From: Kim Phillips @ 2012-04-13 22:26 UTC (permalink / raw)
To: linuxppc-dev
At least for crypto/IPSec, doing so provides users with a better
performance experience out of the box.
Signed-off-by: Kim Phillips <kim.phillips@freescale.com>
---
arch/powerpc/configs/corenet32_smp_defconfig | 1 +
arch/powerpc/configs/corenet64_smp_defconfig | 1 +
arch/powerpc/configs/mpc85xx_smp_defconfig | 1 +
3 files changed, 3 insertions(+)
diff --git a/arch/powerpc/configs/corenet32_smp_defconfig b/arch/powerpc/configs/corenet32_smp_defconfig
index f8aef20..13e7f3c 100644
--- a/arch/powerpc/configs/corenet32_smp_defconfig
+++ b/arch/powerpc/configs/corenet32_smp_defconfig
@@ -32,6 +32,7 @@ CONFIG_HIGH_RES_TIMERS=y
# CONFIG_CORE_DUMP_DEFAULT_ELF_HEADERS is not set
CONFIG_BINFMT_MISC=m
CONFIG_KEXEC=y
+CONFIG_IRQ_ALL_CPUS=y
CONFIG_FORCE_MAX_ZONEORDER=13
CONFIG_FSL_LBC=y
CONFIG_PCI=y
diff --git a/arch/powerpc/configs/corenet64_smp_defconfig b/arch/powerpc/configs/corenet64_smp_defconfig
index 7ed8d4c..00c49b9 100644
--- a/arch/powerpc/configs/corenet64_smp_defconfig
+++ b/arch/powerpc/configs/corenet64_smp_defconfig
@@ -23,6 +23,7 @@ CONFIG_P5020_DS=y
CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BINFMT_MISC=m
+CONFIG_IRQ_ALL_CPUS=y
CONFIG_RAPIDIO=y
CONFIG_FSL_RIO=y
CONFIG_NET=y
diff --git a/arch/powerpc/configs/mpc85xx_smp_defconfig b/arch/powerpc/configs/mpc85xx_smp_defconfig
index abdcd31..608ccc6 100644
--- a/arch/powerpc/configs/mpc85xx_smp_defconfig
+++ b/arch/powerpc/configs/mpc85xx_smp_defconfig
@@ -45,6 +45,7 @@ CONFIG_NO_HZ=y
CONFIG_HIGH_RES_TIMERS=y
CONFIG_BINFMT_MISC=m
CONFIG_MATH_EMULATION=y
+CONFIG_IRQ_ALL_CPUS=y
CONFIG_FORCE_MAX_ZONEORDER=12
CONFIG_PCI=y
CONFIG_PCI_MSI=y
--
1.7.10
^ permalink raw reply related
* P4080 target has 16G memory stability issues ...
From: Robert Sciuk @ 2012-04-13 20:30 UTC (permalink / raw)
To: linuxppc-dev; +Cc: u-boot-request
Dear list(s),
Our P4080 target board is using 2 SODIMM's on each of 2 Controllers
(4x4G DDR3), and we are seeing some memory problems (linux panics) when
beating up large amounts of memory (just under the 16G), on multiple
threads (7 or 8 CPUs).
Our DDR3 configuration is derived from the SPD dump of U-Boot, and we
are using a version based upon the 2011.09 release of U-Boot. Our
firmware memory test, limited as it is to 2G chunks, and a single CPU
shows no problem, it is only using a small test program under Linux and
using multiple cpu's that we see the problems, and we can reproduce the
problem at will, although reducing our memory speed via the RCW does
seem to ameliorate the problem somewhat.
Questions:
- is anyone using a similar configuration?
- is anyone aware of limitations in the U-Boot 2011.09R version
of the mpc8xxx/ddr/* code we need to be aware of?
- any ideas?
We've been pounding our heads on this for a while now, and I'm just
wondering if we are covering old territory here.
Cheers,
Rob.
Robert Sciuk
Senior Designer, R&D.
905.738.3741 xt 22621
^ permalink raw reply
* patch "TTY: hvc, fix TTY refcounting" added to tty tree
From: gregkh @ 2012-04-13 17:54 UTC (permalink / raw)
To: jslaby, gregkh, linuxppc-dev, mikey, sfr
This is a note to let you know that I've just added the patch titled
TTY: hvc, fix TTY refcounting
to my tty git tree which can be found at
git://git.kernel.org/pub/scm/linux/kernel/git/gregkh/tty.git
in the tty-next branch.
The patch will show up in the next release of the linux-next tree
(usually sometime within the next 24 hours during the week.)
The patch will also will be merged in the next major kernel release
during the merge window.
If you have any questions about this process, please let me know.
>From a2f892060f174e5f90041167ca00eb9e68badcb8 Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 13 Apr 2012 10:31:32 +0200
Subject: TTY: hvc, fix TTY refcounting
A -next commit "TTY: HVC, use tty from tty_port" switched the driver
to use tty_port helper for tty refcounting. But it omitted to remove
manual tty refcounting from open, close and hangup. So now we are
getting random crashes caused by use-after-free:
Unable to handle kernel paging request for data at address 0xc0000003f9d550
Faulting instruction address: 0xc0000000001b7f40
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
...
NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
LR [c0000000001b7f14] .__kmalloc+0x44/0x230
Call Trace:
[c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
[c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
[c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
[c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
[c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
[c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
[c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
[c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
Fix that by complete removal of tty_kref_get/put in open/close/hangup
paths.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-and-tested-by: Michael Neuling <mikey@neuling.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: ppc-dev <linuxppc-dev@lists.ozlabs.org>
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
---
drivers/tty/hvc/hvc_console.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
/* Check and then increment for fast path open. */
if (hp->port.count++ > 0) {
spin_unlock_irqrestore(&hp->port.lock, flags);
- /* FIXME why taking a reference here? */
- tty_kref_get(tty);
hvc_kick();
return 0;
} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
*/
if (rc) {
tty_port_tty_set(&hp->port, NULL);
- tty_kref_put(tty);
tty->driver_data = NULL;
tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
spin_unlock_irqrestore(&hp->port.lock, flags);
}
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
@@ -433,7 +429,6 @@ static void hvc_hangup(struct tty_struct *tty)
while(temp_open_count) {
--temp_open_count;
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
}
--
1.7.10
^ permalink raw reply related
* Re: [PATCH] powerpc/e6500: add CPU_FTR_EMB_HV to CPU table
From: Kumar Gala @ 2012-04-13 15:29 UTC (permalink / raw)
To: Scott Wood; +Cc: Marcelo Tosatti, linuxppc-dev, kvm-ppc, kvm
In-Reply-To: <20120411202752.GA12204@schlenkerla.am.freescale.net>
On Apr 11, 2012, at 3:27 PM, Scott Wood wrote:
> e6500 support (commit 10241842fbe900276634fee8d37ec48a7d8a762f,
> "powerpc: Add initial e6500 cpu support" and the introduction of
> CPU_FTR_EMB_HV (commit 73196cd364a2d972d73fa08da9d81ca3215bed68,
> "KVM: PPC: e500mc support") collided during merge, leaving e6500's CPU
> table entry missing CPU_FTR_EMB_HV.
>
> Signed-off-by: Scott Wood <scottwood@freescale.com>
> ---
> Fixup patch for the KVM merge as requested by Marcelo.
>
> arch/powerpc/include/asm/cputable.h | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Acked-by: Kumar Gala <galak@kernel.crashing.org>
- k
^ permalink raw reply
* Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change filename from sata_dwc_460ex.c to sata_dwc_4xx.c
From: Jeff Garzik @ 2012-04-13 14:20 UTC (permalink / raw)
To: Thang Nguyen
Cc: Sergei Shtylyov, Phong Vo, devicetree-discuss, linux-kernel,
Rob Herring, linux-ide, Paul Mackerras, linuxppc-dev
In-Reply-To: <3445364d6d28c2b6ae19817fe6851452@mail.gmail.com>
On 04/13/2012 03:18 AM, Thang Nguyen wrote:
> Thanks Jeff and Sergei,
>
> As your suggestion, I will separate the patch into smaller patches and
> support more features on the SATA DWC driver. The patches I intend to do
> on the SATA DWC are as below:
> - Support hardreset: currently the hardreset is not supported. This
> causes sometime the SATA driver does cause kernel crash because of
> not-determined state.
> - Let device tree specified DMA channel: currently only channel 0 is
> supported (number of channel is set to 1). If device tree not specified
> DMA channel, channel 0 will be used as default.
> - Support ATAPI.
> - Remove dma_interrupt_count. for each DMA transfer, we need 2 interrupts
> for QC completion: transfer completion and DMA transfer completion
> interrupt. The current code wait for both 2 interrupts occur before
> calling qc_complete. This will make out-of-sync state when an interrupt
> lost or when errors occur. The change will process DMA register when DMA
> transfer complete interrupt occur and call qc_issue when command
> completion interrupt occur.
> - Fix NCQ issue and set .can_queue back to ATA_MAX_QUEUE.
> - Support Port Multiplier.
> - Support 2 SATA ports on Maui.
Sounds good, thanks for splitting up the patch into smaller pieces. The
main goal is that separate logical changes should go into separate patches.
Jeff
^ permalink raw reply
* RE: userspace o/p to kernel buffer
From: Jenkins, Clive @ 2012-04-13 11:15 UTC (permalink / raw)
To: Sumesh Kaana, linuxppc-dev
In-Reply-To: <BLU124-W23D62A308B2F33EC51A3D2B43B0@phx.gbl>
> How do I capture all the output of user-space programs into
> a kernel buffer so that I can later read it using debugger ?
>=A0My board doesn't have a console (no serial, no network).
Assuming you are using a shell to start your user-space
programs, you could easily redirect output to /dev/kmsg
then find it in the dmesg buffer afterwards. You may need
to increase the buffer size.
Clive
^ permalink raw reply
* userspace o/p to kernel buffer
From: Sumesh Kaana @ 2012-04-13 9:52 UTC (permalink / raw)
To: linuxppc-dev
[-- Attachment #1: Type: text/plain, Size: 248 bytes --]
Hi,
How do I capture all the output of user-space programs into a kernel buffer so that I can later read it using debugger ? My board doesn't have a console (no serial, no network). Any direction would be of great help.
sumesh.
[-- Attachment #2: Type: text/html, Size: 543 bytes --]
^ permalink raw reply
* [PATCH 1/1] TTY: hvc, fix TTY refcounting
From: Jiri Slaby @ 2012-04-13 8:31 UTC (permalink / raw)
To: gregkh; +Cc: Stephen Rothwell, ppc-dev, linux-kernel, jirislaby
In-Reply-To: <5050.1334304567@neuling.org>
A -next commit "TTY: HVC, use tty from tty_port" switched the driver
to use tty_port helper for tty refcounting. But it omitted to remove
manual tty refcounting from open, close and hangup. So now we are
getting random crashes caused by use-after-free:
Unable to handle kernel paging request for data at address 0xc0000003f9d550
Faulting instruction address: 0xc0000000001b7f40
Oops: Kernel access of bad area, sig: 11 [#1]
...
NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
...
NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
LR [c0000000001b7f14] .__kmalloc+0x44/0x230
Call Trace:
[c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
[c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
[c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
[c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
[c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
[c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
[c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
[c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
Fix that by complete removal of tty_kref_get/put in open/close/hangup
paths.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Reported-and-tested-by: Michael Neuling <mikey@neuling.org>
Cc: Stephen Rothwell <sfr@canb.auug.org.au>
Cc: ppc-dev <linuxppc-dev@lists.ozlabs.org>
---
drivers/tty/hvc/hvc_console.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
/* Check and then increment for fast path open. */
if (hp->port.count++ > 0) {
spin_unlock_irqrestore(&hp->port.lock, flags);
- /* FIXME why taking a reference here? */
- tty_kref_get(tty);
hvc_kick();
return 0;
} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
*/
if (rc) {
tty_port_tty_set(&hp->port, NULL);
- tty_kref_put(tty);
tty->driver_data = NULL;
tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
spin_unlock_irqrestore(&hp->port.lock, flags);
}
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
@@ -433,7 +429,6 @@ static void hvc_hangup(struct tty_struct *tty)
while(temp_open_count) {
--temp_open_count;
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
}
--
1.7.9.2
^ permalink raw reply related
* Re: linux-next: boot failures with next-20120411
From: Michael Neuling @ 2012-04-13 8:09 UTC (permalink / raw)
To: Jiri Slaby
Cc: Stephen Rothwell, Jiri Slaby, Greg Kroah-Hartman, LKML,
linux-next, ppc-dev
In-Reply-To: <4F87DE23.9010907@suse.cz>
Jiri Slaby <jslaby@suse.cz> wrote:
> On 04/13/2012 10:02 AM, Jiri Slaby wrote:
> > On 04/13/2012 04:30 AM, Michael Neuling wrote:
> >> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> >>
> >>> Hi all,
> >>>
> >>> Some (not all) of my PowerPC boot tests have failed like this after
> >>> getting into user mode (this one was just after udev started, but others
> >>> are after other processes getting going):
> >>>
> >>> Unable to handle kernel paging request for data at address 0xc0000003f9d550
> >>> Faulting instruction address: 0xc0000000001b7f40
> >>> Oops: Kernel access of bad area, sig: 11 [#1]
> >>> SMP NR_CPUS=32 NUMA pSeries
> >>> Modules linked in: ehea
> >>> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
> >>> REGS: c0000003f68bf6b0 TRAP: 0300 Not tainted (3.4.0-rc2-autokern1)
> >>> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI> CR: 24422424 XER: 20000001
> >>> SOFTE: 1
> >>> CFAR: 000000000000562c
> >>> DAR: 00c0000003f9d550, DSISR: 40000000
> >>> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
> >>> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00
> >>> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280
> >>> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000
> >>> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000
> >>> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000
> >>> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000
> >>> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0
> >>> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00
> >>> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
> >>> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
> >>> Call Trace:
> >>> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
> >>> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
> >>> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
> >>> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
> >>> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
> >>> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
> >>> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
> >>> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
> >>> Instruction dump:
> >>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008
> >>> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2
> >>> ---[ end trace 366fe6c7ced3bfb0 ]---
> >>>
> >>> This did not happen yesterday. Just wondering if anyone can think of
> >>> anything obvious. Full console log at
> >>> http://ozlabs.org/~sfr/next-20120411.log.bz2
> >>
> >> I managed to bisect this down using pseries_defconfig with next-20120412
> >> to this patch:
> >>
> >> commit 85bbc003b24335e253a392f6a9874103b77abb36
> >> Author: Jiri Slaby <jslaby@suse.cz>
> >> Date: Mon Apr 2 13:54:22 2012 +0200
> >>
> >> TTY: HVC, use tty from tty_port
> >>
> >> The driver already used refcounting. So we just switch it to tty_port
> >> helpers. And switch to tty_port->lock for tty.
> >>
> >> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> >> Cc: linuxppc-dev@lists.ozlabs.org
> >> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
> >>
> >> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
> >> otherwise git barfs) fixes the problem on next-20120412.
> >>
> >> I'm assuming we got the ref count changes wrong somewhere in the patch
> >> but the tty code is beyond me. Jiri, can you take a look?
> >
> > Yeah, I see. I forgot to remove a couple of tty reference drops. The
> > reference is dropped by tty_port_tty_set in open/close/hangup now. Does
> > the attached patch help?
>
> And the patch is incomplete. Now we have a leak. This one should work.
Fixes the problem here.. Thanks.
Tested-by: Michael Neuling <mikey@neuling.org>
^ permalink raw reply
* Re: linux-next: boot failures with next-20120411
From: Jiri Slaby @ 2012-04-13 8:04 UTC (permalink / raw)
To: Jiri Slaby
Cc: Stephen Rothwell, Michael Neuling, Greg Kroah-Hartman, LKML,
linux-next, ppc-dev
In-Reply-To: <4F87DD92.4090601@suse.cz>
[-- Attachment #1: Type: text/plain, Size: 3795 bytes --]
On 04/13/2012 10:02 AM, Jiri Slaby wrote:
> On 04/13/2012 04:30 AM, Michael Neuling wrote:
>> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>>
>>> Hi all,
>>>
>>> Some (not all) of my PowerPC boot tests have failed like this after
>>> getting into user mode (this one was just after udev started, but others
>>> are after other processes getting going):
>>>
>>> Unable to handle kernel paging request for data at address 0xc0000003f9d550
>>> Faulting instruction address: 0xc0000000001b7f40
>>> Oops: Kernel access of bad area, sig: 11 [#1]
>>> SMP NR_CPUS=32 NUMA pSeries
>>> Modules linked in: ehea
>>> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
>>> REGS: c0000003f68bf6b0 TRAP: 0300 Not tainted (3.4.0-rc2-autokern1)
>>> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI> CR: 24422424 XER: 20000001
>>> SOFTE: 1
>>> CFAR: 000000000000562c
>>> DAR: 00c0000003f9d550, DSISR: 40000000
>>> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
>>> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00
>>> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280
>>> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000
>>> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000
>>> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000
>>> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000
>>> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0
>>> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00
>>> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
>>> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
>>> Call Trace:
>>> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
>>> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
>>> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
>>> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
>>> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
>>> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
>>> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
>>> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
>>> Instruction dump:
>>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008
>>> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2
>>> ---[ end trace 366fe6c7ced3bfb0 ]---
>>>
>>> This did not happen yesterday. Just wondering if anyone can think of
>>> anything obvious. Full console log at
>>> http://ozlabs.org/~sfr/next-20120411.log.bz2
>>
>> I managed to bisect this down using pseries_defconfig with next-20120412
>> to this patch:
>>
>> commit 85bbc003b24335e253a392f6a9874103b77abb36
>> Author: Jiri Slaby <jslaby@suse.cz>
>> Date: Mon Apr 2 13:54:22 2012 +0200
>>
>> TTY: HVC, use tty from tty_port
>>
>> The driver already used refcounting. So we just switch it to tty_port
>> helpers. And switch to tty_port->lock for tty.
>>
>> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
>> Cc: linuxppc-dev@lists.ozlabs.org
>> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>>
>> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
>> otherwise git barfs) fixes the problem on next-20120412.
>>
>> I'm assuming we got the ref count changes wrong somewhere in the patch
>> but the tty code is beyond me. Jiri, can you take a look?
>
> Yeah, I see. I forgot to remove a couple of tty reference drops. The
> reference is dropped by tty_port_tty_set in open/close/hangup now. Does
> the attached patch help?
And the patch is incomplete. Now we have a leak. This one should work.
> thanks,
--
js
suse labs
[-- Attachment #2: 0001-HVC-fix-refcounting.patch --]
[-- Type: text/x-patch, Size: 1496 bytes --]
>From 7a55e2976cb5a47e499a6db335ad30ecac2e621c Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 13 Apr 2012 10:00:28 +0200
Subject: [PATCH 1/1] HVC: fix refcounting
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
drivers/tty/hvc/hvc_console.c | 5 -----
1 file changed, 5 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..2d691eb 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -317,8 +317,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
/* Check and then increment for fast path open. */
if (hp->port.count++ > 0) {
spin_unlock_irqrestore(&hp->port.lock, flags);
- /* FIXME why taking a reference here? */
- tty_kref_get(tty);
hvc_kick();
return 0;
} /* else count == 0 */
@@ -338,7 +336,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
*/
if (rc) {
tty_port_tty_set(&hp->port, NULL);
- tty_kref_put(tty);
tty->driver_data = NULL;
tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +390,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
spin_unlock_irqrestore(&hp->port.lock, flags);
}
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
@@ -433,7 +429,6 @@ static void hvc_hangup(struct tty_struct *tty)
while(temp_open_count) {
--temp_open_count;
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
}
--
1.7.9.2
^ permalink raw reply related
* Re: linux-next: boot failures with next-20120411
From: Jiri Slaby @ 2012-04-13 8:02 UTC (permalink / raw)
To: Michael Neuling
Cc: Stephen Rothwell, Jiri Slaby, Greg Kroah-Hartman, LKML,
linux-next, ppc-dev
In-Reply-To: <16710.1334284211@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 3609 bytes --]
On 04/13/2012 04:30 AM, Michael Neuling wrote:
> Stephen Rothwell <sfr@canb.auug.org.au> wrote:
>
>> Hi all,
>>
>> Some (not all) of my PowerPC boot tests have failed like this after
>> getting into user mode (this one was just after udev started, but others
>> are after other processes getting going):
>>
>> Unable to handle kernel paging request for data at address 0xc0000003f9d550
>> Faulting instruction address: 0xc0000000001b7f40
>> Oops: Kernel access of bad area, sig: 11 [#1]
>> SMP NR_CPUS=32 NUMA pSeries
>> Modules linked in: ehea
>> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
>> REGS: c0000003f68bf6b0 TRAP: 0300 Not tainted (3.4.0-rc2-autokern1)
>> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI> CR: 24422424 XER: 20000001
>> SOFTE: 1
>> CFAR: 000000000000562c
>> DAR: 00c0000003f9d550, DSISR: 40000000
>> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
>> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00
>> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280
>> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000
>> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000
>> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000
>> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000
>> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0
>> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00
>> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
>> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
>> Call Trace:
>> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
>> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
>> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
>> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
>> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
>> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
>> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
>> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
>> Instruction dump:
>> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008
>> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2
>> ---[ end trace 366fe6c7ced3bfb0 ]---
>>
>> This did not happen yesterday. Just wondering if anyone can think of
>> anything obvious. Full console log at
>> http://ozlabs.org/~sfr/next-20120411.log.bz2
>
> I managed to bisect this down using pseries_defconfig with next-20120412
> to this patch:
>
> commit 85bbc003b24335e253a392f6a9874103b77abb36
> Author: Jiri Slaby <jslaby@suse.cz>
> Date: Mon Apr 2 13:54:22 2012 +0200
>
> TTY: HVC, use tty from tty_port
>
> The driver already used refcounting. So we just switch it to tty_port
> helpers. And switch to tty_port->lock for tty.
>
> Signed-off-by: Jiri Slaby <jslaby@suse.cz>
> Cc: linuxppc-dev@lists.ozlabs.org
> Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
>
> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
> otherwise git barfs) fixes the problem on next-20120412.
>
> I'm assuming we got the ref count changes wrong somewhere in the patch
> but the tty code is beyond me. Jiri, can you take a look?
Yeah, I see. I forgot to remove a couple of tty reference drops. The
reference is dropped by tty_port_tty_set in open/close/hangup now. Does
the attached patch help?
thanks,
--
js
suse labs
[-- Attachment #2: 0001-HVC-fix-refcounting.patch --]
[-- Type: text/x-patch, Size: 1157 bytes --]
>From cc51efe721f5aa184e119c52c661a1faf865e492 Mon Sep 17 00:00:00 2001
From: Jiri Slaby <jslaby@suse.cz>
Date: Fri, 13 Apr 2012 10:00:28 +0200
Subject: [PATCH 1/1] HVC: fix refcounting
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
---
drivers/tty/hvc/hvc_console.c | 3 ---
1 file changed, 3 deletions(-)
diff --git a/drivers/tty/hvc/hvc_console.c b/drivers/tty/hvc/hvc_console.c
index 6c45cbf..260d4f2 100644
--- a/drivers/tty/hvc/hvc_console.c
+++ b/drivers/tty/hvc/hvc_console.c
@@ -338,7 +338,6 @@ static int hvc_open(struct tty_struct *tty, struct file * filp)
*/
if (rc) {
tty_port_tty_set(&hp->port, NULL);
- tty_kref_put(tty);
tty->driver_data = NULL;
tty_port_put(&hp->port);
printk(KERN_ERR "hvc_open: request_irq failed with rc %d.\n", rc);
@@ -393,7 +392,6 @@ static void hvc_close(struct tty_struct *tty, struct file * filp)
spin_unlock_irqrestore(&hp->port.lock, flags);
}
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
@@ -433,7 +431,6 @@ static void hvc_hangup(struct tty_struct *tty)
while(temp_open_count) {
--temp_open_count;
- tty_kref_put(tty);
tty_port_put(&hp->port);
}
}
--
1.7.9.2
^ permalink raw reply related
* RE: [PATCH 1/1] Add support 2 SATA ports for Maui and change filename from sata_dwc_460ex.c to sata_dwc_4xx.c
From: Thang Nguyen @ 2012-04-13 7:18 UTC (permalink / raw)
To: Jeff Garzik, Sergei Shtylyov
Cc: Phong Vo, devicetree-discuss, linux-kernel, Rob Herring,
linux-ide, Paul Mackerras, linuxppc-dev
In-Reply-To: <4F873573.10406@pobox.com>
Thanks Jeff and Sergei,
As your suggestion, I will separate the patch into smaller patches and
support more features on the SATA DWC driver. The patches I intend to do
on the SATA DWC are as below:
- Support hardreset: currently the hardreset is not supported. This
causes sometime the SATA driver does cause kernel crash because of
not-determined state.
- Let device tree specified DMA channel: currently only channel 0 is
supported (number of channel is set to 1). If device tree not specified
DMA channel, channel 0 will be used as default.
- Support ATAPI.
- Remove dma_interrupt_count. for each DMA transfer, we need 2 interrupts
for QC completion: transfer completion and DMA transfer completion
interrupt. The current code wait for both 2 interrupts occur before
calling qc_complete. This will make out-of-sync state when an interrupt
lost or when errors occur. The change will process DMA register when DMA
transfer complete interrupt occur and call qc_issue when command
completion interrupt occur.
- Fix NCQ issue and set .can_queue back to ATA_MAX_QUEUE.
- Support Port Multiplier.
- Support 2 SATA ports on Maui.
Regards,
Thang Nguyen-
-----Original Message-----
From: Jeff Garzik [mailto:jgpobox@gmail.com] On Behalf Of Jeff Garzik
Sent: Friday, April 13, 2012 3:05 AM
To: Sergei Shtylyov
Cc: Thang Q. Nguyen; Benjamin Herrenschmidt; Paul Mackerras; Grant Likely;
Rob Herring; linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org;
linux-ide@vger.kernel.org; devicetree-discuss@lists.ozlabs.org
Subject: Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change
filename from sata_dwc_460ex.c to sata_dwc_4xx.c
On 04/03/2012 07:56 AM, Sergei Shtylyov wrote:
> Hello.
>
> On 03-04-2012 14:12, Thang Q. Nguyen wrote:
>
>> Signed-off-by: Thang Q. Nguyen<tqnguyen@apm.com>
>> ---
>> Changes for v2:
>> - Use git rename feature to change the driver to the newname and for
>> easier review.
>
>> arch/powerpc/boot/dts/bluestone.dts | 21 +
>> drivers/ata/Makefile | 2 +-
>> drivers/ata/{sata_dwc_460ex.c => sata_dwc_4xx.c} | 1371
>> ++++++++++++++--------
>> 3 files changed, 904 insertions(+), 490 deletions(-)
>> rename drivers/ata/{sata_dwc_460ex.c => sata_dwc_4xx.c} (56%)
>
> You submitted a magapatch doing several things at once (some even
> needlessly) and even in two areas of the kernel. This needs proper
> splitting/description.
Agreed...
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to AppliedMicro Corporation or its subsidiaries.
It is to be used solely for the purpose of furthering the parties' business relationship.
All unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message.
^ permalink raw reply
* Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change filename from sata_dwc_460ex.c to sata_dwc_4xx.c
From: Thang Q. Nguyen @ 2012-04-13 3:29 UTC (permalink / raw)
To: Sergei Shtylyov
Cc: devicetree-discuss, linux-kernel, Rob Herring, linux-ide,
Paul Mackerras, Jeff Garzik, linuxppc-dev
In-Reply-To: <4F8417DB.3040502@mvista.com>
[-- Attachment #1: Type: text/plain, Size: 5918 bytes --]
Hi,
Two SATA device nodes in bluestone.dts uses the same structure as SATA node
in the canyonlands.dts. All boards having SATA DWC currently use this
structure. So, changing it will need to change all corresponding device
tree. The current sata_dwc_460ex.c agrees with this structure.
I want to give more information for SATA controller on Maui:
- There are 2 SATA controllers on Maui, each has its own register set. But
they use the same DMA registers for processing DMA transfer.
- For DMA transfer, each SATA controller will use its own DMA channel in
the DMA registers.
- DMA controller driver must be supported and enabled in order to issue
SATA DMA transfer.
I agree that declaring the same DMA register information in 2 device nodes
can cause confliction but I think the driver can handle it. In case this
approach is not accepted, I will add only 1 SATA port to the bluestone.dts
and another port will be considered later.
For the APM confidential information from my email, it is added
automatically by the APM system. I have submitted a ticket for asking IT
not adding it into my email and it is in-progress. I will continue to
submit patches after the ticket is processed.
Regards,
Thang Nguyen -
On Tue, Apr 10, 2012 at 6:22 PM, Sergei Shtylyov <sshtylyov@mvista.com>wrote:
> Hello.
>
>
> On 10-04-2012 7:46, Thang Nguyen wrote:
>
> Hi Sergei,
>> Thanks for your review.
>>
>
> On Maui, there are 2 separate SATA controllers but they share the same
>> AHBDMA controller. Each SATA controller is assigned a fixed DMA channel on
>> the AHBDMA (channel 0 is assigned to SATA controller 0 and channel 1 is
>> assigned to SATA controller 1).
>> For the 460EX, there is only 1 SATA controller and it uses channel 0 for
>> transferring data.
>>
>
> In my opinion, in the case of Maui, we can use the same DMA information in
>> 2 device nodes as they use the same DMA controller. And in another CPU, if
>> they use different DMA controller, the corresponding information will also
>> be different.
>>
>
> No, either the DMA controller should be a separate device node, or both
> ports and DMA controller should be packed into the single device node. The
> way you're doing it is incorrect because it creates memory resource
> conflict between devices when they are instantiated as platfrom devices.
>
>
> Regards,
>> Thang Nguyen -
>> -----Original Message-----
>> From: Sergei Shtylyov [mailto:sshtylyov@mvista.com]
>> Sent: Monday, April 09, 2012 5:13 PM
>> To: Thang Q. Nguyen
>> Cc: Benjamin Herrenschmidt; Paul Mackerras; Jeff Garzik; Grant Likely; Rob
>> Herring; linuxppc-dev@lists.ozlabs.org; linux-kernel@vger.kernel.org;
>> linux-ide@vger.kernel.org; devicetree-discuss@lists.**ozlabs.org<devicetree-discuss@lists.ozlabs.org>
>> Subject: Re: [PATCH 1/1] Add support 2 SATA ports for Maui and change
>> filename from sata_dwc_460ex.c to sata_dwc_4xx.c
>>
>
> Hello.
>>
>
> On 03-04-2012 14:12, Thang Q. Nguyen wrote:
>>
>
> Signed-off-by: Thang Q. Nguyen<tqnguyen@apm.com>
>>>
>> [...]
>>
>
> diff --git a/arch/powerpc/boot/dts/**bluestone.dts
>>>
>> b/arch/powerpc/boot/dts/**bluestone.dts
>>
>>> index cfa23bf..803fda6 100644
>>> --- a/arch/powerpc/boot/dts/**bluestone.dts
>>> +++ b/arch/powerpc/boot/dts/**bluestone.dts
>>> @@ -155,6 +155,27 @@
>>> /*RXDE*/ 0x5 0x4>;
>>> };
>>>
>>> + /* SATA DWC devices */
>>> + SATA0: sata@bffd1000 {
>>> + compatible = "amcc,sata-apm821xx";
>>> + reg =<4 0xbffd1000 0x800 /* SATA0 */
>>> + 4 0xbffd0800 0x400>; /* AHBDMA */
>>> + dma-channel=<0>;
>>> + interrupt-parent =<&UIC0>;
>>> + interrupts =<26 4 /* SATA0 */
>>> + 25 4>; /* AHBDMA */
>>> + };
>>> +
>>> + SATA1: sata@bffd1800 {
>>> + compatible = "amcc,sata-apm821xx";
>>> + reg =<4 0xbffd1800 0x800 /* SATA1 */
>>> + 4 0xbffd0800 0x400>; /* AHBDMA */
>>> + dma-channel=<1>;
>>> + interrupt-parent =<&UIC0>;
>>> + interrupts =<27 4 /* SATA1 */
>>> + 25 4>; /* AHBDMA */
>>> + };
>>> +
>>>
>>
> So, this is dual SATA controller, not dual port SATA controller?
>> BTW, it's wrong to have the same AHBDMA resource in two device nodes I
>> think.
>>
>
> MBR, Sergei
>>
>
> Can you get rid of the following? It looks stupid when you post to the
> maliing list.
>
> CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
>> is for the sole use of the intended recipient(s) and contains information
>> that is confidential and proprietary to AppliedMicro Corporation or its
>> subsidiaries.
>> It is to be used solely for the purpose of furthering the parties'
>> business relationship.
>> All unauthorized review, use, disclosure or distribution is prohibited.
>> If you are not the intended recipient, please contact the sender by reply
>> e-mail
>> and destroy all copies of the original message.
>>
>
> WBR, Sergei
>
--
*Thang Q. Nguyen **|** Staff SW Eng.*
C: +849.7684.7607 | O: +848.3770.0640
F: +848.3770.0641 | tqnguyen@apm.com
CONFIDENTIALITY NOTICE: This e-mail message, including any attachments,
is for the sole use of the intended recipient(s) and contains information
that is confidential and proprietary to AppliedMicro Corporation or its subsidiaries.
It is to be used solely for the purpose of furthering the parties' business relationship.
All unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by reply e-mail
and destroy all copies of the original message.
[-- Attachment #2: Type: text/html, Size: 10323 bytes --]
^ permalink raw reply
* Re: linux-next: boot failures with next-20120411
From: Stephen Rothwell @ 2012-04-13 2:57 UTC (permalink / raw)
To: Michael Neuling; +Cc: Greg Kroah-Hartman, linux-next, ppc-dev, Jiri Slaby, LKML
In-Reply-To: <16710.1334284211@neuling.org>
[-- Attachment #1: Type: text/plain, Size: 661 bytes --]
Hi all,
On Fri, 13 Apr 2012 12:30:11 +1000 Michael Neuling <mikey@neuling.org> wrote:
>
> I managed to bisect this down using pseries_defconfig with next-20120412
> to this patch:
>
> commit 85bbc003b24335e253a392f6a9874103b77abb36
> Author: Jiri Slaby <jslaby@suse.cz>
> Date: Mon Apr 2 13:54:22 2012 +0200
>
> TTY: HVC, use tty from tty_port
Thanks for that, Mikey.
> Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
> otherwise git barfs) fixes the problem on next-20120412.
I will revert those commits form linux-next today.
--
Cheers,
Stephen Rothwell sfr@canb.auug.org.au
[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: linux-next: boot failures with next-20120411
From: Michael Neuling @ 2012-04-13 2:30 UTC (permalink / raw)
To: Stephen Rothwell, Jiri Slaby, Greg Kroah-Hartman
Cc: linux-next, ppc-dev, LKML
In-Reply-To: <20120411165835.415e546374a54ea94669b0c6@canb.auug.org.au>
Stephen Rothwell <sfr@canb.auug.org.au> wrote:
> Hi all,
>
> Some (not all) of my PowerPC boot tests have failed like this after
> getting into user mode (this one was just after udev started, but others
> are after other processes getting going):
>
> Unable to handle kernel paging request for data at address 0xc0000003f9d550
> Faulting instruction address: 0xc0000000001b7f40
> Oops: Kernel access of bad area, sig: 11 [#1]
> SMP NR_CPUS=32 NUMA pSeries
> Modules linked in: ehea
> NIP: c0000000001b7f40 LR: c0000000001b7f14 CTR: c0000000000e04f0
> REGS: c0000003f68bf6b0 TRAP: 0300 Not tainted (3.4.0-rc2-autokern1)
> MSR: 800000000280b032 <SF,VEC,VSX,EE,FP,ME,IR,DR,RI> CR: 24422424 XER: 20000001
> SOFTE: 1
> CFAR: 000000000000562c
> DAR: 00c0000003f9d550, DSISR: 40000000
> TASK = c0000003f8818000[3192] 'kdump' THREAD: c0000003f68bc000 CPU: 5
> GPR00: 0000000000000000 c0000003f68bf930 c000000000ce1d40 c0000003fe00ec00
> GPR04: 00000000000002d0 0000000000000038 c0000003f8f935e8 c000000000e55280
> GPR08: 0000000000000011 c000000000bcb280 c000000000bcb1e8 000000000028a000
> GPR12: 0000000024422424 c00000000f33bc80 00000fffdd90a770 0000000000081000
> GPR16: c0000003f846c000 000000000de4f7a0 f00000000de4f7a0 0000000000000000
> GPR20: c0000003f8365408 c0000003f8365480 c0000003f8e5d110 0000000000000000
> GPR24: 0000000000000100 c0000003f8365400 c0000000001e5424 00000000000002d0
> GPR28: 0000000000000800 00c0000003f9d550 c000000000c5b718 c0000003fe00ec00
> NIP [c0000000001b7f40] .__kmalloc+0x70/0x230
> LR [c0000000001b7f14] .__kmalloc+0x44/0x230
> Call Trace:
> [c0000003f68bf930] [c0000003f68bf9b0] 0xc0000003f68bf9b0 (unreliable)
> [c0000003f68bf9e0] [c0000000001e5424] .alloc_fdmem+0x24/0x70
> [c0000003f68bfa60] [c0000000001e54f8] .alloc_fdtable+0x88/0x130
> [c0000003f68bfaf0] [c0000000001e5924] .dup_fd+0x384/0x450
> [c0000003f68bfbd0] [c00000000009a310] .copy_process+0x880/0x11d0
> [c0000003f68bfcd0] [c00000000009aee0] .do_fork+0x70/0x400
> [c0000003f68bfdc0] [c0000000000141c4] .sys_clone+0x54/0x70
> [c0000003f68bfe30] [c000000000009aa0] .ppc_clone+0x8/0xc
> Instruction dump:
> 4bff9281 2ba30010 7c7f1b78 40dd00f4 e96d0040 e93f0000 7ce95a14 e9070008
> 7fa9582a 2fbd0000 41de0054 e81f0022 <7f3d002a> 38000000 886d01f2 980d01f2
> ---[ end trace 366fe6c7ced3bfb0 ]---
>
> This did not happen yesterday. Just wondering if anyone can think of
> anything obvious. Full console log at
> http://ozlabs.org/~sfr/next-20120411.log.bz2
I managed to bisect this down using pseries_defconfig with next-20120412
to this patch:
commit 85bbc003b24335e253a392f6a9874103b77abb36
Author: Jiri Slaby <jslaby@suse.cz>
Date: Mon Apr 2 13:54:22 2012 +0200
TTY: HVC, use tty from tty_port
The driver already used refcounting. So we just switch it to tty_port
helpers. And switch to tty_port->lock for tty.
Signed-off-by: Jiri Slaby <jslaby@suse.cz>
Cc: linuxppc-dev@lists.ozlabs.org
Signed-off-by: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Reverting this commit (and 0146b6939074ebe14ece3604fd00e7be128a3812
otherwise git barfs) fixes the problem on next-20120412.
I'm assuming we got the ref count changes wrong somewhere in the patch
but the tty code is beyond me. Jiri, can you take a look?
Mikey
^ permalink raw reply
* Re: [PATCH v5 00/21] EEH reorganization
From: Anton Blanchard @ 2012-04-13 2:03 UTC (permalink / raw)
To: Gavin Shan; +Cc: linuxppc-dev
In-Reply-To: <20120413073931.0c36169b@kryten>
Hi,
> I just hit this on mainline from today (3.4.0-rc2-00065-gf549e08).
> Haven't had a chance to narrow it down yet.
Looking closer, it was caused by an EEH error at boot. It looks like
the Mellanox infiniband card gets an error when probed by their
firmware tool (mstmread), but only if the kernel driver is not loaded.
I see this EEH error back on 3.0, so it's not new.
The question now is why we oops in the EEH code on mainline.
Anton
------------[ cut here ]------------
WARNING: at arch/powerpc/platforms/pseries/eeh.c:492
Modules linked in:
NIP: c000000000056cc4 LR: c000000000056cc0 CTR: c00000000051dd60
REGS: c000001f3953f6a0 TRAP: 0700 Not tainted (3.4.0-rc2-00065-gf549e08-dirty)
MSR: 8000000000029032 <SF,EE,ME,IR,DR,RI> CR: 28004482 XER: 0000000f
SOFTE: 0
CFAR: c00000000074ea30
TASK = c000001f39685040[19058] 'mstmread' THREAD: c000001f3953c000 CPU: 38
GPR00: c000000000056cc0 c000001f3953f920 c000000000bd3a28 0000000000000021
GPR04: 0000000000000000 ffffffffffffffff 00000000000323f7 0000000000000000
GPR08: 000000006365203c c000000000b10a20 0000000000020000 c000000000a74cc0
GPR12: 0000000024004422 c00000000eda8500 000000003a58582e 00000000583a5858
GPR16: 000000002f585858 0000000069636573 000000002f646576 0000000010003b48
GPR20: 00000fffc7a3d17c 0000000000000058 0000000000000004 c000001f3953fb90
GPR24: 0000000000000000 0000000000000000 c000000000c77088 c000003e6fffeee8
GPR28: c000000000d82680 0000000000000000 c000000000c770d0 0000000000000000
NIP [c000000000056cc4] .eeh_dn_check_failure+0x304/0x320
LR [c000000000056cc0] .eeh_dn_check_failure+0x300/0x320
Call Trace:
[c000001f3953f920] [c000000000056cc0] .eeh_dn_check_failure+0x300/0x320 (unreliable)
[c000001f3953f9d0] [c00000000002717c] .rtas_read_config+0x13c/0x1b0
[c000001f3953fa70] [c0000000003d543c] .pci_user_read_config_dword+0xcc/0x150
[c000001f3953fb20] [c0000000003e19d8] .pci_read_config+0xe8/0x2a0
[c000001f3953fc00] [c00000000022d330] .read+0x130/0x210
[c000001f3953fce0] [c0000000001a723c] .vfs_read+0xec/0x1e0
[c000001f3953fd80] [c0000000001a73ec] .SyS_pread64+0xbc/0xd0
[c000001f3953fe30] [c000000000009780] syscall_exit+0x0/0x7c
Instruction dump:
7f83e378 48001909 60000000 2fbf0000 419e002c e89f00d8 2fa40000 409e0008
e89f0098 e8629fb8 486f7d39 60000000 <0fe00000> 3b200001 4bfffdb4 e8829fa8
---[ end trace a6e6d788c9869e00 ]---
EEH: Detected PCI bus error on device 0006:01:00.0
EEH: This PCI device has failed 1 times in the last hour:
EEH: Bus location=U78AB.001.WZSGRFL-P1-C4-T1 driver= pci addr=0006:01:00.0
EEH: Device location=U78AB.001.WZSGRFL-P1-C4-T1 driver= pci addr=0006:01:00.0
EEH: of node=/pci@800000020000203/pci1014,415@0
EEH: PCI device/vendor: 673c15b3
EEH: PCI cmd/status register: 00100140
^ permalink raw reply
* Re: [RFC] powerpc: set_dma_ops for pci hotplug
From: Hiroo Matsumoto @ 2012-04-13 0:03 UTC (permalink / raw)
To: linuxppc-dev
In-Reply-To: <4F867083.2090200@jp.fujitsu.com>
Hi
I'm so sorry, but there is a better way than this way with
pcibios_enable_device() for issue.
I will write another code soon, so please wait.
Regards.
Hiroo MATSUMOTO
> Hi
>
>
> I'm trying to use PCI Express Hot Plug on powerpc platform.
> But PCI driver returns error when hotplug.
> Error log is as below.
> http://www.spinics.net/lists/linux-pci/msg14534.html
>
> Some of PCI driver needs dma_ops.
> On x86 platform, dma_ops is getting from external variable.
> On powerpc platform, dma_ops is getting from archdata.dma_ops in struct
> device.
> There is a problem that archdata.dma_ops is set only when boot with
> pcibios_setup_bus_devices but not set when hotplug.
> So when hotplug, PCI driver's probe will return error.
>
> I add code of checking and setting dma_ops in pcibios_enable_device.
> It is called from pci_enable_device_xxx in PCI driver's probe before
> checking dma_ops.
> And PCI driver works good when hotplug.
>
>
> Regards.
>
> Hiroo MATSUMOTO
>
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox