Re: [PATCH] powerpc: Fix i8259 interrupt driver kernel crash on ML510
On Thu, 2009-09-03 at 09:57 -0600, Grant Likely wrote: > From: Roderick Colenbrander > > This patch fixes a null pointer exception caused by removal of > 'ack()' for level interrupts in the Xilinx interrupt driver. A recent > change to the xilinx interrupt controller removed the ack hook for > level irqs. > > Signed-off-by: Roderick Colenbrander > Signed-off-by: Grant Likely > --- Acked-by: Benjamin Herrenschmidt My git trees aren't at hand, so Linus feel free to merge that directly. Cheers, Ben. > > Hi Ben & Linus, > > This is a last minute bug fix must go into 2.6.31. This patch > is needed to prevent a kernel panic on Xilinx ml510 boards. > > I've also pushed the patch out to my git tree if you'd prefer to pull: > > The following changes since commit 326ba5010a5429a5a528b268b36a5900d4ab0eba: > Linus Torvalds (1): > Linux 2.6.31-rc8 > > are available in the git repository at: > > git://git.secretlab.ca/git/linux-2.6 merge > > Roderick Colenbrander (1): > powerpc: Fix i8259 interrupt driver kernel crash on ML510 > > arch/powerpc/sysdev/xilinx_intc.c |1 - > 1 files changed, 0 insertions(+), 1 deletions(-) > > > > diff --git a/arch/powerpc/sysdev/xilinx_intc.c > b/arch/powerpc/sysdev/xilinx_intc.c > index 3ee1fd3..40edad5 100644 > --- a/arch/powerpc/sysdev/xilinx_intc.c > +++ b/arch/powerpc/sysdev/xilinx_intc.c > @@ -234,7 +234,6 @@ static void xilinx_i8259_cascade(unsigned int irq, struct > irq_desc *desc) > generic_handle_irq(cascade_irq); > > /* Let xilinx_intc end the interrupt */ > - desc->chip->ack(irq); > desc->chip->unmask(irq); > } > ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)
Hi Adam,
> Are you sure there is L2 cache on the 440?
It depends on the SoC you are using. SoC like 460EX (Canyonlands board)
have L2Cache.
It seems you are using a Sequoia board, which has a 440EPx SoC. 440EPx
has a 440 cpu core, but no L2Cache.
Could you please tell me which SoC you are using?
You can also refer to the appropriate dts file to see if there is L2C.
For example, in canyonlands.dts (460EX based board), we have the L2C
entry.
L2C0: l2c {
...
}
>I am seeing this problem with our custom IDE driver which is based on
>pretty old code. Our driver uses pci_alloc_consistent() to allocate the
>physical DMA memory and alloc_pages() to allocate a virtual page. It
>then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I
>should convert these to the DMA API calls as you suggest.
Could you give more details on the consistency problem? It is a good
idea to change to the new DMA APIs, but pci_alloc_consistent() should
work too
Thanks
Prodyut
On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote:
> On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> > Hi Adam,
> >
> > If you have a look in include/asm-ppc/pgtable.h for the following
section:
> > #ifdef CONFIG_44x
> > #define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED |
_PAGE_GUARDED)
> > #else
> > #define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED)
> > #endif
> >
> > Try adding _PAGE_COHERENT to the appropriate line above and see if
that
> > fixes your issue - this causes the 'M' bit to be set on the page
which
> > sure enforce cache coherency. If it doesn't, you'll need to check
the
> > 'M' bit isn't being masked out in head_44x.S (it was originally
masked
> > out on arch/powerpc, but was fixed in later kernels when the cache
> > coherency issues with non-SMP systems were resolved).
>
> I have some doubts about the usefulness of doing that for 4xx. AFAIK,
> the 440 core just ignores M.
>
> The problem lies probably elsewhere. Maybe the L2 cache coherency
isn't
> enabled or not working ?
>
> The L1 cache on 440 is simply not coherent, so drivers have to make
sure
> they use the appropriate DMA APIs which will do cache flushing when
> needed.
>
> Adam, what driver is causing you that sort of problems ?
>
> Cheers,
> Ben.
>
>
--
Adam Zilkie
Software Designer,
International Datacasting Corp.
This message and the documents attached hereto are intended only for the
addressee and may contain privileged or confidential information. Any
unauthorized disclosure is strictly prohibited. If you have received
this message in error, please notify us immediately so that we may
correct our internal records. Please then delete the original message.
Thank you.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
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.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 6/6] PPC64-HWBKPT: Adapt kexec and samples code to recognise PPC64 hw-breakpoint
Modify kexec code to disable DABR registers before a reboot. Adapt the samples
code to populate PPC64-arch specific fields.
Signed-off-by: K.Prasad
---
arch/powerpc/kernel/machine_kexec_64.c |3 +++
samples/hw_breakpoint/data_breakpoint.c |4
2 files changed, 7 insertions(+)
Index: linux-2.6-tip.ppc64_hbkpt/arch/powerpc/kernel/machine_kexec_64.c
===
--- linux-2.6-tip.ppc64_hbkpt.orig/arch/powerpc/kernel/machine_kexec_64.c
+++ linux-2.6-tip.ppc64_hbkpt/arch/powerpc/kernel/machine_kexec_64.c
@@ -24,6 +24,7 @@
#include /* _end */
#include
#include
+#include
int default_machine_kexec_prepare(struct kimage *image)
{
@@ -214,6 +215,7 @@ static void kexec_prepare_cpus(void)
put_cpu();
local_irq_disable();
+ hw_breakpoint_disable();
}
#else /* ! SMP */
@@ -233,6 +235,7 @@ static void kexec_prepare_cpus(void)
if (ppc_md.kexec_cpu_down)
ppc_md.kexec_cpu_down(0, 0);
local_irq_disable();
+ hw_breakpoint_disable();
}
#endif /* SMP */
Index: linux-2.6-tip.ppc64_hbkpt/samples/hw_breakpoint/data_breakpoint.c
===
--- linux-2.6-tip.ppc64_hbkpt.orig/samples/hw_breakpoint/data_breakpoint.c
+++ linux-2.6-tip.ppc64_hbkpt/samples/hw_breakpoint/data_breakpoint.c
@@ -54,6 +54,10 @@ static int __init hw_break_module_init(v
sample_hbp.info.type = HW_BREAKPOINT_WRITE;
sample_hbp.info.len = HW_BREAKPOINT_LEN_4;
#endif /* CONFIG_X86 */
+#ifdef CONFIG_PPC64
+ sample_hbp.info.name = ksym_name;
+ sample_hbp.info.type = HW_BREAKPOINT_WRITE;
+#endif /* CONFIG_PPC64 */
sample_hbp.triggered = (void *)sample_hbp_handler;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 5/6] PPC64-HWBKPT: Modify Data storage exception code to recognise DABR match first
Modify Data storage exception code to first lookout for a DABR match before
recognising a kprobe or xmon exception.
Signed-off-by: K.Prasad
---
arch/powerpc/mm/fault.c | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
Index: linux-2.6-tip.hbkpt/arch/powerpc/mm/fault.c
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/mm/fault.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/mm/fault.c
@@ -137,6 +137,12 @@ int __kprobes do_page_fault(struct pt_re
error_code &= 0x4820;
else
is_write = error_code & DSISR_ISSTORE;
+
+ if (error_code & DSISR_DABRMATCH) {
+ /* DABR match */
+ do_dabr(regs, address, error_code);
+ return 0;
+ }
#else
is_write = error_code & ESR_DST;
#endif /* CONFIG_4xx || CONFIG_BOOKE */
@@ -151,14 +157,6 @@ int __kprobes do_page_fault(struct pt_re
if (!user_mode(regs) && (address >= TASK_SIZE))
return SIGSEGV;
-#if !(defined(CONFIG_4xx) || defined(CONFIG_BOOKE))
- if (error_code & DSISR_DABRMATCH) {
- /* DABR match */
- do_dabr(regs, address, error_code);
- return 0;
- }
-#endif /* !(CONFIG_4xx || CONFIG_BOOKE)*/
-
if (in_atomic() || mm == NULL) {
if (!user_mode(regs))
return SIGSEGV;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 4/6] PPC64-HWBKPT: Modify process/processor code to recognise hardware debug registers
Modify process handling code to recognise hardware debug registers during copy
and flush operations. Introduce a new TIF_DEBUG task flag to indicate a
process's use of debug register. Load the debug register values into a
new CPU during initialisation.
Signed-off-by: K.Prasad
---
arch/powerpc/kernel/process.c | 15 +++
arch/powerpc/kernel/smp.c |2 ++
2 files changed, 17 insertions(+)
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/process.c
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/process.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/process.c
@@ -50,6 +50,7 @@
#include
#ifdef CONFIG_PPC64
#include
+#include
#endif
#include
#include
@@ -254,8 +255,10 @@ void do_dabr(struct pt_regs *regs, unsig
11, SIGSEGV) == NOTIFY_STOP)
return;
+#ifndef CONFIG_PPC64
if (debugger_dabr_match(regs))
return;
+#endif
/* Clear the DAC and struct entries. One shot trigger */
#if defined(CONFIG_BOOKE)
@@ -372,8 +375,13 @@ struct task_struct *__switch_to(struct t
#endif /* CONFIG_SMP */
+#ifdef CONFIG_PPC64
+ if (unlikely(test_tsk_thread_flag(new, TIF_DEBUG)))
+ arch_install_thread_hw_breakpoint(new);
+#else
if (unlikely(__get_cpu_var(current_dabr) != new->thread.dabr))
set_dabr(new->thread.dabr);
+#endif /* CONFIG_PPC64 */
#if defined(CONFIG_BOOKE)
/* If new thread DAC (HW breakpoint) is the same then leave it */
@@ -550,6 +558,10 @@ void show_regs(struct pt_regs * regs)
void exit_thread(void)
{
discard_lazy_cpu_state();
+#ifdef CONFIG_PPC64
+ if (unlikely(test_tsk_thread_flag(current, TIF_DEBUG)))
+ flush_thread_hw_breakpoint(current);
+#endif /* CONFIG_PPC64 */
}
void flush_thread(void)
@@ -672,6 +684,9 @@ int copy_thread(unsigned long clone_flag
* function.
*/
kregs->nip = *((unsigned long *)ret_from_fork);
+
+ if (unlikely(test_tsk_thread_flag(current, TIF_DEBUG)))
+ copy_thread_hw_breakpoint(current, p, clone_flags);
#else
kregs->nip = (unsigned long)ret_from_fork;
#endif
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/smp.c
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/smp.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/smp.c
@@ -48,6 +48,7 @@
#include
#ifdef CONFIG_PPC64
#include
+#include
#endif
#ifdef DEBUG
@@ -537,6 +538,7 @@ int __devinit start_secondary(void *unus
local_irq_enable();
+ load_debug_registers();
cpu_idle();
return 0;
}
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 3/6] PPC64-HWBKPT: Modify ptrace code to use Hardware Breakpoint interfaces
Modify the ptrace code to use the hardware breakpoint interfaces for user-space.
Signed-off-by: K.Prasad
---
arch/powerpc/kernel/ptrace.c | 43 +++
1 file changed, 43 insertions(+)
Index: linux-2.6-tip.hbkpt/arch/powerpc/kernel/ptrace.c
===
--- linux-2.6-tip.hbkpt.orig/arch/powerpc/kernel/ptrace.c
+++ linux-2.6-tip.hbkpt/arch/powerpc/kernel/ptrace.c
@@ -37,6 +37,7 @@
#include
#include
#include
+#include
/*
* does not yet catch signals sent when the child dies.
@@ -757,11 +758,24 @@ void user_disable_single_step(struct tas
void ptrace_triggered(struct hw_breakpoint *bp, struct pt_regs *regs)
{
+ /*
+* Unregister the breakpoint request here since ptrace has defined a
+* one-shot behaviour for breakpoint exceptions in PPC64.
+* The SIGTRAP signal is generated automatically for us in do_dabr().
+* We don't have to do anything here
+*/
+ unregister_user_hw_breakpoint(current, bp);
+ kfree(bp);
}
int ptrace_set_debugreg(struct task_struct *task, unsigned long addr,
unsigned long data)
{
+#ifdef CONFIG_PPC64
+ struct thread_struct *thread = &(task->thread);
+ struct hw_breakpoint *bp;
+ int ret;
+#endif
/* For ppc64 we support one DABR and no IABR's at the moment (ppc64).
* For embedded processors we support one DAC and no IAC's at the
* moment.
@@ -791,6 +805,35 @@ int ptrace_set_debugreg(struct task_stru
if (data && !(data & DABR_TRANSLATION))
return -EIO;
+#ifdef CONFIG_PPC64
+ bp = thread->hbp[0];
+ if (data == 0) {
+ if (bp) {
+ unregister_user_hw_breakpoint(task, bp);
+ kfree(bp);
+ }
+ return 0;
+ }
+
+ if (bp) {
+ bp->info.type = data & HW_BREAKPOINT_RW;
+ task->thread.dabr = bp->info.address = data;
+ return modify_user_hw_breakpoint(task, bp);
+ }
+ bp = kzalloc(sizeof(struct hw_breakpoint), GFP_KERNEL);
+ if (!bp)
+ return -ENOMEM;
+
+ /* Store the type of breakpoint */
+ bp->info.type = data & HW_BREAKPOINT_RW;
+ bp->triggered = ptrace_triggered;
+ task->thread.dabr = bp->info.address = data;
+
+ ret = register_user_hw_breakpoint(task, bp);
+ if (ret)
+ return ret;
+#endif /* CONFIG_PPC64 */
+
/* Move contents to the DABR register */
task->thread.dabr = data;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 2/6] PPC64-HWBKPT: Introduce PPC64 specific Hardware Breakpoint interfaces
Introduce PPC64 implementation for the generic hardware breakpoint interfaces
defined in kernel/hw_breakpoint.c. Enable the HAVE_HW_BREAKPOINT flag and the
Makefile.
Signed-off-by: K.Prasad
---
arch/powerpc/Kconfig|1
arch/powerpc/kernel/Makefile|2
arch/powerpc/kernel/hw_breakpoint.c | 342
arch/powerpc/kernel/ptrace.c|4
4 files changed, 348 insertions(+), 1 deletion(-)
Index: linux-2.6-tip.ppc64_hbkpt/arch/powerpc/Kconfig
===
--- linux-2.6-tip.ppc64_hbkpt.orig/arch/powerpc/Kconfig
+++ linux-2.6-tip.ppc64_hbkpt/arch/powerpc/Kconfig
@@ -126,6 +126,7 @@ config PPC
select HAVE_SYSCALL_WRAPPERS if PPC64
select GENERIC_ATOMIC64 if PPC32
select HAVE_PERF_COUNTERS
+ select HAVE_HW_BREAKPOINT if PPC64
config EARLY_PRINTK
bool
Index: linux-2.6-tip.ppc64_hbkpt/arch/powerpc/kernel/Makefile
===
--- linux-2.6-tip.ppc64_hbkpt.orig/arch/powerpc/kernel/Makefile
+++ linux-2.6-tip.ppc64_hbkpt/arch/powerpc/kernel/Makefile
@@ -35,7 +35,7 @@ obj-$(CONFIG_PPC64) += setup_64.o sys_p
signal_64.o ptrace32.o \
paca.o cpu_setup_ppc970.o \
cpu_setup_pa6t.o \
- firmware.o nvram_64.o
+ firmware.o nvram_64.o hw_breakpoint.o
obj64-$(CONFIG_RELOCATABLE)+= reloc_64.o
obj-$(CONFIG_PPC64)+= vdso64/
obj-$(CONFIG_ALTIVEC) += vecemu.o
Index: linux-2.6-tip.ppc64_hbkpt/arch/powerpc/kernel/hw_breakpoint.c
===
--- /dev/null
+++ linux-2.6-tip.ppc64_hbkpt/arch/powerpc/kernel/hw_breakpoint.c
@@ -0,0 +1,342 @@
+/*
+ * HW_breakpoint: a unified kernel/user-space hardware breakpoint facility,
+ * using the CPU's debug registers.
+ *
+ * This program is free software; you can redistribute it and/or modify
+ * it under the terms of the GNU General Public License as published by
+ * the Free Software Foundation; either version 2 of the License, or
+ * (at your option) any later version.
+ *
+ * This program is distributed in the hope that it will be useful,
+ * but WITHOUT ANY WARRANTY; without even the implied warranty of
+ * MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+ * GNU General Public License for more details.
+ *
+ * You should have received a copy of the GNU General Public License
+ * along with this program; if not, write to the Free Software
+ * Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111-1307, USA.
+ *
+ * Copyright 2009 IBM Corporation
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/* Store the kernel-space breakpoint address value */
+static unsigned long kdabr;
+
+/*
+ * Temporarily stores address for DABR before it is written by the
+ * single-step handler routine
+ */
+static DEFINE_PER_CPU(unsigned long, dabr_data);
+static DEFINE_PER_CPU(struct hw_breakpoint*, last_hit_bp);
+
+/* Disable breakpoints on the physical debug register */
+void arch_disable_hw_breakpoint(void)
+{
+ set_dabr(0);
+}
+
+void arch_update_kernel_hw_breakpoint(void *unused)
+{
+ struct hw_breakpoint *bp;
+
+ /* Check if there is nothing to update */
+ if (hbp_kernel_pos == HBP_NUM)
+ return;
+
+ bp = per_cpu(this_hbp_kernel[hbp_kernel_pos], get_cpu());
+ if (bp == NULL)
+ kdabr = 0;
+ else
+ kdabr = (bp->info.address & ~HW_BREAKPOINT_ALIGN) |
+ bp->info.type | DABR_TRANSLATION;
+ set_dabr(kdabr);
+ put_cpu();
+}
+
+/*
+ * Install the thread breakpoints in their debug registers.
+ */
+void arch_install_thread_hw_breakpoint(struct task_struct *tsk)
+{
+ set_dabr(tsk->thread.dabr);
+}
+
+/*
+ * Clear the DABR which contains the thread-specific breakpoint address
+ */
+void arch_uninstall_thread_hw_breakpoint()
+{
+ set_dabr(0);
+}
+
+/*
+ * Store a breakpoint's encoded address, length, and type.
+ */
+int arch_store_info(struct hw_breakpoint *bp, struct task_struct *tsk)
+{
+ unsigned long sym_addr;
+
+ /* Symbol names from user-space are rejected */
+ if (tsk) {
+ if (bp->info.name)
+ return -EINVAL;
+ return 0;
+ }
+ /*
+* User-space requests will always have the address field populated
+* For kernel-addresses, either the address or symbol name can be
+* specified.
+*/
+ if (bp->info.name) {
+ sym_addr = (unsigned long)kallsyms_lookup_name(bp->info.name);
+ if (bp->info.address) {
+ if (bp->info.address != sym_addr)
+
[Patch 1/6] PPC64-HWBKPT: Prepare the PowerPC platform for HW Breakpoint infrastructure
Prepare the PowerPC code for HW Breakpoint infrastructure patches by including
relevant constant definitions and function declarations.
Signed-off-by: K.Prasad
---
arch/powerpc/include/asm/hw_breakpoint.h | 61 +++
arch/powerpc/include/asm/processor.h |1
arch/powerpc/include/asm/reg.h |3 +
arch/powerpc/include/asm/thread_info.h |2 +
4 files changed, 67 insertions(+)
Index: linux-2.6-tip.ppc64_hbkpt/arch/powerpc/include/asm/hw_breakpoint.h
===
--- /dev/null
+++ linux-2.6-tip.ppc64_hbkpt/arch/powerpc/include/asm/hw_breakpoint.h
@@ -0,0 +1,61 @@
+#ifndef_PPC64_HW_BREAKPOINT_H
+#define_PPC64_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#define__ARCH_HW_BREAKPOINT_H
+#ifdef CONFIG_PPC64
+
+struct arch_hw_breakpoint {
+ int type;
+ char*name; /* Contains name of the symbol to set bkpt */
+ unsigned long address;
+ unsigned long symbolsize;
+};
+
+#include
+#include
+#include
+
+#define HW_BREAKPOINT_READ DABR_DATA_READ
+#define HW_BREAKPOINT_WRITE DABR_DATA_WRITE
+#define HW_BREAKPOINT_RW (DABR_DATA_READ | DABR_DATA_WRITE)
+
+#define HW_BREAKPOINT_ALIGN 0x7
+/* Maximum permissible length of any HW Breakpoint */
+#define HW_BREAKPOINT_LEN 0x8
+
+extern struct hw_breakpoint *hbp_kernel[HBP_NUM];
+DECLARE_PER_CPU(struct hw_breakpoint*, this_hbp_kernel[HBP_NUM]);
+extern unsigned int hbp_user_refcount[HBP_NUM];
+
+extern void arch_install_thread_hw_breakpoint(struct task_struct *tsk);
+extern void arch_uninstall_thread_hw_breakpoint(void);
+extern int arch_validate_hwbkpt_settings(struct hw_breakpoint *bp,
+ struct task_struct *tsk);
+extern void arch_update_user_hw_breakpoint(int pos, struct task_struct *tsk);
+extern void arch_flush_thread_hw_breakpoint(struct task_struct *tsk);
+extern void arch_update_kernel_hw_breakpoint(void *);
+extern void arch_disable_hw_breakpoint(void);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+unsigned long val, void *data);
+
+extern void flush_thread_hw_breakpoint(struct task_struct *tsk);
+extern int copy_thread_hw_breakpoint(struct task_struct *tsk,
+ struct task_struct *child, unsigned long clone_flags);
+extern void load_debug_registers(void);
+extern void ptrace_triggered(struct hw_breakpoint *bp, struct pt_regs *regs);
+
+static inline void hw_breakpoint_disable(void)
+{
+ set_dabr(0);
+}
+
+#else
+static inline void hw_breakpoint_disable(void)
+{
+ /* Function is defined only on PPC64 for now */
+}
+#endif /* CONFIG_PPC64 */
+#endif /* __KERNEL__ */
+#endif /* _PPC64_HW_BREAKPOINT_H */
+
Index: linux-2.6-tip.ppc64_hbkpt/arch/powerpc/include/asm/processor.h
===
--- linux-2.6-tip.ppc64_hbkpt.orig/arch/powerpc/include/asm/processor.h
+++ linux-2.6-tip.ppc64_hbkpt/arch/powerpc/include/asm/processor.h
@@ -177,6 +177,7 @@ struct thread_struct {
#ifdef CONFIG_PPC64
unsigned long start_tb; /* Start purr when proc switched in */
unsigned long accum_tb; /* Total accumilated purr for process */
+ struct hw_breakpoint *hbp[HBP_NUM];
#endif
unsigned long dabr; /* Data address breakpoint register */
#ifdef CONFIG_ALTIVEC
Index: linux-2.6-tip.ppc64_hbkpt/arch/powerpc/include/asm/reg.h
===
--- linux-2.6-tip.ppc64_hbkpt.orig/arch/powerpc/include/asm/reg.h
+++ linux-2.6-tip.ppc64_hbkpt/arch/powerpc/include/asm/reg.h
@@ -26,6 +26,8 @@
#include
#endif /* CONFIG_8xx */
+#define INSTRUCTION_LEN4 /* Length of any instruction */
+
#define MSR_SF_LG 63 /* Enable 64 bit mode */
#define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */
#define MSR_HV_LG 60 /* Hypervisor state */
@@ -184,6 +186,7 @@
#define CTRL_TE 0x00c0 /* thread enable */
#define CTRL_RUNLATCH0x1
#define SPRN_DABR 0x3F5 /* Data Address Breakpoint Register */
+#define HBP_NUM 1 /* Number of physical HW breakpoint registers */
#define DABR_TRANSLATION (1UL << 2)
#define DABR_DATA_WRITE (1UL << 1)
#define DABR_DATA_READ (1UL << 0)
Index: linux-2.6-tip.ppc64_hbkpt/arch/powerpc/include/asm/thread_info.h
===
--- linux-2.6-tip.ppc64_hbkpt.orig/arch/powerpc/include/asm/thread_info.h
+++ linux-2.6-tip.ppc64_hbkpt/arch/powerpc/include/asm/thread_info.h
@@ -112,6 +112,7 @@ static inline struct thread_info *curren
#define TIF_FREEZE 14 /* Freezing for suspend */
#define TIF_RUNLATCH 15 /* Is the runlatch enabled? */
#define TIF_ABI_PENDING16 /* 32/64 bi
[Patch 0/6] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver IX
Hi All, Please find a new set of patches with the changes as listed below. These patches have to be applied over the set of patches sent to LKML here: http://lkml.org/lkml/2009/8/28/272 that enable per-cpu breakpoint support and a few new APIs. Changelog - ver IX --- - Invocation of user-defined callback will be 'trigger-after-execute' (except for ptrace). - Creation of a new global per-CPU breakpoint structure to help invocation of user-defined callback from single-step handler. - Validation before registration will fail only if the address does not match the kernel symbol's (if specified) resolved address (through kallsyms_lookup_name()). - 'symbolsize' value is expected to within the range contained by the symbol's starting address and the end of a double-word boundary (8 Bytes). - PPC64's arch-dependant code is now aware of 'cpumask' in 'struct hw_breakpoint' and can accomodate requests for a subset of CPUs in the system. - Introduced arch_disable_hw_breakpoint() required for _hw_breakpoint() APIs. Kindly let me know your comments on the same. Thanks, K.Prasad Changelog - ver VIII --- - Reverting changes to allow one-shot breakpoints only for ptrace requests. - Minor changes in sanity checking in arch_validate_hwbkpt_settings(). - put_cpu_no_resched() is no longer available. Converted to put_cpu(). Changelog - ver VII --- - Allow the one-shot behaviour for exception handlers to be defined by the user. A new 'is_one_shot' flag is added to 'struct arch_hw_breakpoint'. Changelog - ver VI -- The task of identifying 'genuine' breakpoint exceptions from those caused by 'out-of-range' accesses turned out to be more tricky than originally thought. Some changes to this effect were made in version IV of this patchset, but they were not sufficient for user-space. Basically the breakpoint address received through ptrace is always aligned to 8-bytes since ptrace receives an encoded 'data' (consisting of address | translation_enable | bkpt_type), and the size of the symbol is not known. However for kernel-space addresses, the symbol-size can be determined using kallsyms_lookup_size_offset() and this is used to check if DAR (in the exception context) is 'bkpt_address <= DAR <= (bkpt_address + symbol_size)', failing which we conclude it as a stray exception. The following changes are made to enable check: - Addition of a symbolsize field in 'struct arch_hw_breakpoint' field. - Store the size of the 'watched' kernel symbol into 'symbolsize' field in arch_store_info(0 routine. - Verify if the above described condition is true when is_one_shot is FALSE in hw_breakpoint_handler(). Changelog - ver V -- - Breakpoint requests from ptrace (for user-space) are designed to be one-shot in PPC64. The patch contains changes to retain this behaviour by returning early in hw_breakpoint_handler() [without re-initialising DABR] and unregistering the user-space request in ptrace_triggered(). It is safe to make a unregister_user_hw_breakpoint() call from the breakpoint exception context [through ptrace_triggered()] without giving rise to circular locking-dependancy. This is because there can be no kernel code running on the CPU (which received the exception) with the same spinlock held. - Minor change in 'type' member of 'struct arch_hw_breakpoint' from u8 to 'int'. Changelog - ver IV -- - While DABR register requires double-word (8 bytes) aligned addresses, i.e. the breakpoint is active over a range of 8 bytes, PPC64 allows byte-level addressability. This may lead to stray exceptions which have to be ignored in hw_breakpoint_handler(), when DAR != (Breakpoint request address). However DABR will be populated with the requested breakpoint address aligned to the previous double-word address. The code is now modified to store user-requested address in 'bp->info.address' but update the DABR with a double-word aligned address. - Please note that the Data Breakpoint facility in Xmon is broken as of 2.6.29 and the same has not been integrated into this facility as described in Ver I. Changelog - ver III -- - Patches are based on commit 08f16e060bf54bdc34f800ed8b5362cdeda75d8b of -tip tree. - The declarations in arch/powerpc/include/asm/hw_breakpoint.h are done only if CONFIG_PPC64 is defined. This eliminates the need to conditionally include this header file. - load_debug_registers() is done in start_secondary() i.e. during CPU initialisation. - arch_check_va_<> routines in hw_breakpoint.c are now replaced with a much simpler is_kernel_addr() check in arch_validate_hwbkpt_settings() - Return code of hw_breakpoint_handler() when triggered due to Lazy debug register switching is now changed to NOTIFY_STOP. - The ptrace code no longer sets the TIF_DEBUG task flag as it is proposed to be done in register_user_hw_breakpoint() routine. - hw_breakpoint_handler() is now modified to use
Re: [RFC] net/fs_enet: send a reset request to the PHY on init
On Wed, Sep 2, 2009 at 5:04 AM, Sebastian Andrzej Siewior wrote: > Usually u-boot sends a phy request in its network init routine. An uboot > without network support doesn't do it and I endup without working > network. I still can switch between 10/100Mbit (according to the LED on > the hub and phy registers) but I can't send or receive any data. > > At this point I'm not sure if the PowerON Reset takes the PHY a few > nsecs too early out of reset or if this reset is required and everyone > relies on U-boot performing this reset. > > Signed-off-by: Sebastian Andrzej Siewior > --- > This is done on a custom mpc512x board. Unfortunately I don't have other > boards to check. The PHY is a AMD Am79C874, phylib uses the generic one. > > drivers/net/fs_enet/fs_enet-main.c | 3 ++- > 1 files changed, 2 insertions(+), 1 deletions(-) > > diff --git a/drivers/net/fs_enet/fs_enet-main.c > b/drivers/net/fs_enet/fs_enet-main.c > index ee15402..a3c962b 100644 > --- a/drivers/net/fs_enet/fs_enet-main.c > +++ b/drivers/net/fs_enet/fs_enet-main.c > @@ -823,7 +823,8 @@ static int fs_init_phy(struct net_device *dev) > } > > fep->phydev = phydev; > - > + phy_write(phydev, MII_BMCR, BMCR_RESET); > + udelay(1); What version of the kernel are you using? The line numbers don't match up with kernel mainline, so I wonder if this is before or after the OF MDIO rework changes. Regardless, this doesn't look right. It certainly isn't right for the driver to do an unconditional PHY reset when it doesn't actually know what phy is attached. For most boards I'm sure this is not desirable because it will cause a delay while the PHY auto negotiates. Depending on when the first network traffic begins, can cause several seconds of boot delay. Best would be to do this in U-Boot. Otherwise, I think I would rather see it at phy_device probe time. At least then it would be on a per-phy basis, or could be controlled by a property in the device tree so that all boards don't get the same impact. g. -- Grant Likely, B.Sc., P.Eng. Secret Lab Technologies Ltd. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
On Thu, Sep 03, 2009 at 12:04:50PM -0400, Adam Zilkie wrote: >Ben, > >Thanks for your info. > >Are you sure there is L2 cache on the 440? It depends on which 440 SoC you have. It also depends on that being configured in the kernel even if it does exist. >I am seeing this problem with our custom IDE driver which is based on >pretty old code. Our driver uses pci_alloc_consistent() to allocate the >physical DMA memory and alloc_pages() to allocate a virtual page. It >then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I >should convert these to the DMA API calls as you suggest. I would suggest updating the code. I have no idea if that is the problem, but it should probably be done anyway. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
Ben, Thanks for your info. Are you sure there is L2 cache on the 440? I am seeing this problem with our custom IDE driver which is based on pretty old code. Our driver uses pci_alloc_consistent() to allocate the physical DMA memory and alloc_pages() to allocate a virtual page. It then uses pci_map_sg() to map to a scatter/gather buffer. Perhaps I should convert these to the DMA API calls as you suggest. Regards, Adam On Thu, 2009-09-03 at 19:57 +1000, Benjamin Herrenschmidt wrote: > On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote: > > Hi Adam, > > > > If you have a look in include/asm-ppc/pgtable.h for the following section: > > #ifdef CONFIG_44x > > #define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED) > > #else > > #define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED) > > #endif > > > > Try adding _PAGE_COHERENT to the appropriate line above and see if that > > fixes your issue - this causes the 'M' bit to be set on the page which > > sure enforce cache coherency. If it doesn't, you'll need to check the > > 'M' bit isn't being masked out in head_44x.S (it was originally masked > > out on arch/powerpc, but was fixed in later kernels when the cache > > coherency issues with non-SMP systems were resolved). > > I have some doubts about the usefulness of doing that for 4xx. AFAIK, > the 440 core just ignores M. > > The problem lies probably elsewhere. Maybe the L2 cache coherency isn't > enabled or not working ? > > The L1 cache on 440 is simply not coherent, so drivers have to make sure > they use the appropriate DMA APIs which will do cache flushing when > needed. > > Adam, what driver is causing you that sort of problems ? > > Cheers, > Ben. > > -- Adam Zilkie Software Designer, International Datacasting Corp. This message and the documents attached hereto are intended only for the addressee and may contain privileged or confidential information. Any unauthorized disclosure is strictly prohibited. If you have received this message in error, please notify us immediately so that we may correct our internal records. Please then delete the original message. Thank you. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
Chris,
I noticed the following comment in pgtable.h:
* - CACHE COHERENT bit (M) has no effect on PPC440 core, because it
* doesn't support SMP. So we can use this as software bit, like
* DIRTY.
And _PAGE_COHERENT is not defined for the 44x (giving a compile error
when I add it the _PAGE_BASE line as you suggested). This would confirm
that the M bit is meaningless for the PPC440
Regards,
Adam
On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote:
> Hi Adam,
>
> If you have a look in include/asm-ppc/pgtable.h for the following section:
> #ifdef CONFIG_44x
> #define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
> #else
> #define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED)
> #endif
>
> Try adding _PAGE_COHERENT to the appropriate line above and see if that
> fixes your issue - this causes the 'M' bit to be set on the page which
> sure enforce cache coherency. If it doesn't, you'll need to check the
> 'M' bit isn't being masked out in head_44x.S (it was originally masked
> out on arch/powerpc, but was fixed in later kernels when the cache
> coherency issues with non-SMP systems were resolved).
>
> The patch I had fixed two problems on 2.6.26 for 'powerpc':
> 1) It stopped the 'M' bit being masked out (head_32.S)
> 2) It set the cache coherency ('M' bit) flag on each page table entry
> (pgtable-ppc32.h)
>
> Hope this helps!
>
> Cheers,
> Chris
>
> Adam Zilkie wrote:
> > Hi Chris,
> >
> > I am having a problem similar to what you described in this discussion.
> > We are using the ppc arch with 2.6.24 with CONFIG_SEQUOIA with compiles
> > arch/ppc/kernel/head_44x.c (quite different
> > from /arch/powerpc/kernel/head_32.S). I would like to apply your
> > backporting patch to this architecture. Any help would be appreciated.
> >
> > Regards,
> > Adam
> >
> >
>
>
--
Adam Zilkie
Software Designer,
International Datacasting Corp.
This message and the documents attached hereto are intended only for the
addressee and may contain privileged or confidential information. Any
unauthorized disclosure is strictly prohibited. If you have received this
message in error, please notify us immediately so that we may correct our
internal records. Please then delete the original message. Thank you.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH] powerpc: Fix i8259 interrupt driver kernel crash on ML510
From: Roderick Colenbrander This patch fixes a null pointer exception caused by removal of 'ack()' for level interrupts in the Xilinx interrupt driver. A recent change to the xilinx interrupt controller removed the ack hook for level irqs. Signed-off-by: Roderick Colenbrander Signed-off-by: Grant Likely --- Hi Ben & Linus, This is a last minute bug fix must go into 2.6.31. This patch is needed to prevent a kernel panic on Xilinx ml510 boards. I've also pushed the patch out to my git tree if you'd prefer to pull: The following changes since commit 326ba5010a5429a5a528b268b36a5900d4ab0eba: Linus Torvalds (1): Linux 2.6.31-rc8 are available in the git repository at: git://git.secretlab.ca/git/linux-2.6 merge Roderick Colenbrander (1): powerpc: Fix i8259 interrupt driver kernel crash on ML510 arch/powerpc/sysdev/xilinx_intc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c index 3ee1fd3..40edad5 100644 --- a/arch/powerpc/sysdev/xilinx_intc.c +++ b/arch/powerpc/sysdev/xilinx_intc.c @@ -234,7 +234,6 @@ static void xilinx_i8259_cascade(unsigned int irq, struct irq_desc *desc) generic_handle_irq(cascade_irq); /* Let xilinx_intc end the interrupt */ - desc->chip->ack(irq); desc->chip->unmask(irq); } ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Fix i8259 kernel crash on ML510
>From 11a2072b285c2eb0f19980ad729229d4ebf22291 Mon Sep 17 00:00:00 2001 From: Roderick Colenbrander Date: Thu, 3 Sep 2009 15:11:08 +0200 Subject: [PATCH] This patch fixes a null pointer exception caused by removal of 'ack()' for level interrupts in the Xilinx interrupt driver. --- arch/powerpc/sysdev/xilinx_intc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c index 3ee1fd3..40edad5 100644 --- a/arch/powerpc/sysdev/xilinx_intc.c +++ b/arch/powerpc/sysdev/xilinx_intc.c @@ -234,7 +234,6 @@ static void xilinx_i8259_cascade(unsigned int irq, struct irq_desc *desc) generic_handle_irq(cascade_irq); /* Let xilinx_intc end the interrupt */ - desc->chip->ack(irq); desc->chip->unmask(irq); } -- 1.6.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Fix i8259 kernel crash on ML510 [with signed-off]
Hi, This is the same patch but with a signed-off message which I forgot. Regards, Roderick Colenbrander Signed-off-by: Roderick Colenbrander >From 11a2072b285c2eb0f19980ad729229d4ebf22291 Mon Sep 17 00:00:00 2001 From: Roderick Colenbrander Date: Thu, 3 Sep 2009 15:11:08 +0200 Subject: [PATCH] This patch fixes a null pointer exception caused by removal of 'ack()' for level interrupts in the Xilinx interrupt driver. --- arch/powerpc/sysdev/xilinx_intc.c |1 - 1 files changed, 0 insertions(+), 1 deletions(-) diff --git a/arch/powerpc/sysdev/xilinx_intc.c b/arch/powerpc/sysdev/xilinx_intc.c index 3ee1fd3..40edad5 100644 --- a/arch/powerpc/sysdev/xilinx_intc.c +++ b/arch/powerpc/sysdev/xilinx_intc.c @@ -234,7 +234,6 @@ static void xilinx_i8259_cascade(unsigned int irq, struct irq_desc *desc) generic_handle_irq(cascade_irq); /* Let xilinx_intc end the interrupt */ - desc->chip->ack(irq); desc->chip->unmask(irq); } -- 1.6.0.4 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: time jumps forward/backwards
Benjamin Gamsa wrote: Benjamin Herrenschmidt wrote: On Mon, 2009-08-31 at 23:57 -0400, Benjamin Gamsa wrote: Sean MacLennan wrote: On Mon, 31 Aug 2009 22:20:00 -0400 Benjamin Gamsa wrote: For what it's worth, the problem occurs even when ntp is not even started. This is grasping, but could it have anything to do with the jiffies wrapping near startup? I don't know how to test it, but I don't think so, since there are multiple of these glitches over an extended period of time. I'm not familiar with all the FSL processor variants, but is this an UP or an SMP platform ? In the later case, are all the core timebases properly synchronized ? This a UP with a single e500 core. I take it from the lack of follow-ups that no one has any good ideas as to what might be going wrong? Since the problem seems to be confined to situations where the date is around the epoch, I guess I'll just work-around the problem by setting the date to a more recent date on startup. -- Ben Gamsa b...@somanetworks.com SOMA Networks 312 Adelaide St. W. Suite 600 Toronto, Ontario, M5V1R2 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
In our case, we were suffering coherency issues on an 8260 when using
DMA with PCI. Setting the 'M' bit cured all of our DMA coherency issues.
There is a comment in "pgtable-ppc32.h" on 2.6.29.6 that says:
"We always set _PAGE_COHERENT when SMP is enabled *or* the processor
might need it for DMA coherency". Freescale had also suggested setting
the 'M' bit when we submitted a support request.
I've no idea how this bit affects other PowerPC chips. Looking briefly
through some of the header files, it looks as if the 'M' bit should not
be set for 44x, so the issue is probably not the same as the one I had.
Cheers,
Chris
Wrobel Heinz-R39252 wrote:
Hi,
This doesn't seem right. If we are talking about a single CPU core chip,
i.e., just one data cache, then setting M is typically a) useless and
could even b) cause a performance penalty depending on a chip's
implementation.
The M bit is required if *other* cores with caches need to see changes
for coherency of their caches. You wouldn't set it for one core only
because your own core knows about its own cache.
The possible performance penalty could happen because you need some way
to tell the others that they better intercept a transaction. And that
could, depending on the chip, by a clock extra or so per transaction.
Now, in theory, a DMA engine could have caches, read from cache content
first, and could snoop the bus on global transactions like another core,
but I have never heard of such a beast.
Hope this helps,
Heinz
-Original Message-
From: linuxppc-dev-bounces+heinz.wrobel=freescale@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+heinz.wrobel=freescale@lists.ozlabs.org
] On Behalf Of Chris Pringle
Sent: Donnerstag, 3. September 2009 10:05
To: azil...@datacast.com
Cc: Tom Burns; Andrea Zypchen; linuxppc-dev@lists.ozlabs.org
Subject: Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
Hi Adam,
If you have a look in include/asm-ppc/pgtable.h for the following
section:
#ifdef CONFIG_44x
#define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
#else
#define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED)
#endif
Try adding _PAGE_COHERENT to the appropriate line above and see if that
fixes your issue - this causes the 'M' bit to be set on the page which
sure enforce cache coherency. If it doesn't, you'll need to check the
'M' bit isn't being masked out in head_44x.S (it was originally masked
out on arch/powerpc, but was fixed in later kernels when the cache
coherency issues with non-SMP systems were resolved).
The patch I had fixed two problems on 2.6.26 for 'powerpc':
1) It stopped the 'M' bit being masked out (head_32.S)
2) It set the cache coherency ('M' bit) flag on each page table entry
(pgtable-ppc32.h)
Hope this helps!
Cheers,
Chris
Adam Zilkie wrote:
Hi Chris,
I am having a problem similar to what you described in this
discussion.
We are using the ppc arch with 2.6.24 with CONFIG_SEQUOIA with
compiles arch/ppc/kernel/head_44x.c (quite different from
/arch/powerpc/kernel/head_32.S). I would like to apply your
backporting patch to this architecture. Any help would be appreciated.
Regards,
Adam
Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
RE: AW: PowerPC PCI DMA issues (prefetch/coherency?)
Hi,
This doesn't seem right. If we are talking about a single CPU core chip,
i.e., just one data cache, then setting M is typically a) useless and
could even b) cause a performance penalty depending on a chip's
implementation.
The M bit is required if *other* cores with caches need to see changes
for coherency of their caches. You wouldn't set it for one core only
because your own core knows about its own cache.
The possible performance penalty could happen because you need some way
to tell the others that they better intercept a transaction. And that
could, depending on the chip, by a clock extra or so per transaction.
Now, in theory, a DMA engine could have caches, read from cache content
first, and could snoop the bus on global transactions like another core,
but I have never heard of such a beast.
Hope this helps,
Heinz
-Original Message-
From: linuxppc-dev-bounces+heinz.wrobel=freescale@lists.ozlabs.org
[mailto:linuxppc-dev-bounces+heinz.wrobel=freescale@lists.ozlabs.org
] On Behalf Of Chris Pringle
Sent: Donnerstag, 3. September 2009 10:05
To: azil...@datacast.com
Cc: Tom Burns; Andrea Zypchen; linuxppc-dev@lists.ozlabs.org
Subject: Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
Hi Adam,
If you have a look in include/asm-ppc/pgtable.h for the following
section:
#ifdef CONFIG_44x
#define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
#else
#define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED)
#endif
Try adding _PAGE_COHERENT to the appropriate line above and see if that
fixes your issue - this causes the 'M' bit to be set on the page which
sure enforce cache coherency. If it doesn't, you'll need to check the
'M' bit isn't being masked out in head_44x.S (it was originally masked
out on arch/powerpc, but was fixed in later kernels when the cache
coherency issues with non-SMP systems were resolved).
The patch I had fixed two problems on 2.6.26 for 'powerpc':
1) It stopped the 'M' bit being masked out (head_32.S)
2) It set the cache coherency ('M' bit) flag on each page table entry
(pgtable-ppc32.h)
Hope this helps!
Cheers,
Chris
Adam Zilkie wrote:
> Hi Chris,
>
> I am having a problem similar to what you described in this
discussion.
> We are using the ppc arch with 2.6.24 with CONFIG_SEQUOIA with
> compiles arch/ppc/kernel/head_44x.c (quite different from
> /arch/powerpc/kernel/head_32.S). I would like to apply your
> backporting patch to this architecture. Any help would be appreciated.
>
> Regards,
> Adam
>
>
--
__
Chris Pringle
Software Design Engineer
Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK
Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com
Miranda Technologies Limited
Registered in England and Wales CN 02017053 Registered Office: James
House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
powerpc test branch build failure with 6xx defconfig + PERF_CTRS
With benh's test branch, I'm seeing this trying to build a 6xx defconfig with CONFIG_PPC_PERF_CTRS=y: arch/powerpc/kernel/perf_counter.c: In function 'power_check_constraints': arch/powerpc/kernel/perf_counter.c:352: error: the frame size of 1152 bytes is larger than 1024 bytes cheers signature.asc Description: This is a digitally signed message part ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: PPC PCI bus registers
On Wed, 2009-09-02 at 16:44 -0700, Eddie Dawydiuk wrote: > Hello, > > I have a question regarding reading PCI bus registers from a user space > application running on a PPC SBC. Seeing as though the PCI bus is little > endian > and PPC is big endian is it typical that one must perform a byte swap on all > 16 > and 32 bit register reads? > > I've found this is true on a custom board I am working on(with an FPGA > connected > via the PCI bus) and as a result I've added a byte swap command in busybox to > accommodate this feature... Note that powerpc has efficient load/store reverse instructions that perform the byteswap for you. We use them for IOs in the kernel for example. Also, if you're going to access a PCI device directly, beware of other issues such as ordering. PPC is an out of order architecture, you need to ensure you add the appropriate memory barriers if you want to ensure you accesses are done in the order you write them in your program. For "standard" stuff that doesn't involve DMA or locks, an eieio after both MMIO loads and stores should do the trick. If you need to order vs. DMA and/or locks, you may want to look at what the kernel does in io.h Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
On Thu, 2009-09-03 at 09:05 +0100, Chris Pringle wrote: > Hi Adam, > > If you have a look in include/asm-ppc/pgtable.h for the following section: > #ifdef CONFIG_44x > #define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED) > #else > #define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED) > #endif > > Try adding _PAGE_COHERENT to the appropriate line above and see if that > fixes your issue - this causes the 'M' bit to be set on the page which > sure enforce cache coherency. If it doesn't, you'll need to check the > 'M' bit isn't being masked out in head_44x.S (it was originally masked > out on arch/powerpc, but was fixed in later kernels when the cache > coherency issues with non-SMP systems were resolved). I have some doubts about the usefulness of doing that for 4xx. AFAIK, the 440 core just ignores M. The problem lies probably elsewhere. Maybe the L2 cache coherency isn't enabled or not working ? The L1 cache on 440 is simply not coherent, so drivers have to make sure they use the appropriate DMA APIs which will do cache flushing when needed. Adam, what driver is causing you that sort of problems ? Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [v4 PATCH 1/5]: cpuidle: Cleanup drivers/cpuidle/cpuidle.c
On Thu, 2009-09-03 at 10:12 +0530, Arun R Bharadwaj wrote: > > OK, that's a start I guess. Best would be to replace all of pm_idle with > > cpuidle, which is what should have been done from the very start. > > > > If cpuidle cannot fully replace the pm_idle functionality, then it needs > > to fix that. But having two layers of idle functions is just silly. > > > > Looking at patch 2 and 3, you're making the same mistake on power, after > > those patches there are multiple ways of registering idle functions, one > > through some native interface and one through cpuidle, this strikes me > > as undesirable. > > > > If cpuidle is a good idle function manager, then it should be good > > enough to be the sole one, if its not, then why bother with it at all. > > > > Okay, I'm giving this approach a shot now. i.e. trying to make cpuidle > as _the_ sole idle function manager. This would mean doing away with > pm_idle and ppc_md.power_save. And, cpuidle_idle_call() which is the > main idle loop of cpuidle, present in drivers/cpuidle/cpuidle.c will > have to be called from arch specific code of cpu_idle() > > Also this would mean enabling cpuidle for all platforms, even if the > platform doesn't have multiple idle states. So suppose a platform doesnt > have multiple states, it wouldn't want the bloated code of cpuidle > governors, and would want just a simple cpuidle loop. Do talk to the powerpc maintainers about this. But yes, something like that should be doable. AFAICT the whole governor thing is optional and cpuidle provides a spinning idle loop by default, and platforms can always register a simple alternative when they set up bits -- the only thing to be careful about is not creating a chicken-egg problem where the platform setup runs before cpuidle is able to register a new handler or something. I'd be delighted to see the end of pm_idle on x86. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
ucc_geth.c - NETDEV WATCHDOG: eth2 Tx transmit timeout
Dear All, Currently we are using the MPC8360E processor, for that we face the problem with Ethernet port (UCC) port, which one configures as RMII mode. We get the error like "NETDEV WATCHDOG: eth2 tx transmit timeout", When applied more load on port. Can u give me any solution for this problem; I will see the entire patch related it but not found solution of this problem. Any one has any idea about it how to resolve it. Wait for Replay Regards, Shailesh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: AW: PowerPC PCI DMA issues (prefetch/coherency?)
Hi Adam,
If you have a look in include/asm-ppc/pgtable.h for the following section:
#ifdef CONFIG_44x
#define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED | _PAGE_GUARDED)
#else
#define _PAGE_BASE(_PAGE_PRESENT | _PAGE_ACCESSED)
#endif
Try adding _PAGE_COHERENT to the appropriate line above and see if that
fixes your issue - this causes the 'M' bit to be set on the page which
sure enforce cache coherency. If it doesn't, you'll need to check the
'M' bit isn't being masked out in head_44x.S (it was originally masked
out on arch/powerpc, but was fixed in later kernels when the cache
coherency issues with non-SMP systems were resolved).
The patch I had fixed two problems on 2.6.26 for 'powerpc':
1) It stopped the 'M' bit being masked out (head_32.S)
2) It set the cache coherency ('M' bit) flag on each page table entry
(pgtable-ppc32.h)
Hope this helps!
Cheers,
Chris
Adam Zilkie wrote:
Hi Chris,
I am having a problem similar to what you described in this discussion.
We are using the ppc arch with 2.6.24 with CONFIG_SEQUOIA with compiles
arch/ppc/kernel/head_44x.c (quite different
from /arch/powerpc/kernel/head_32.S). I would like to apply your
backporting patch to this architecture. Any help would be appreciated.
Regards,
Adam
--
__
Chris Pringle
Software Design Engineer
Miranda Technologies Ltd.
Hithercroft Road
Wallingford
Oxfordshire OX10 9DG
UK
Tel. +44 1491 820206
Fax. +44 1491 820001
www.miranda.com
Miranda Technologies Limited
Registered in England and Wales CN 02017053
Registered Office: James House, Mere Park, Dedmere Road, Marlow, Bucks, SL7 1FJ
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: MPC866 FEC's Receive processing thru pre allocated buffers
Ganesh Kumar wrote on 03/09/2009 06:45:14: > > Hi Tjernlund, > > Thanks a lot for the reply. > > I checked in my code regarding to the invalidate/flushing of the > data cache. In the fec_init its been done by calling the sequence > >/* Make it uncached. > */ > pte = va_to_pte(mem_addr); > pte_val(*pte) |= _PAGE_NO_CACHE; > flush_tlb_page(init_mm.mmap, mem_addr); > So I did the same thing whenever I allocated new skb, but the > problems still showed up, then I saw one comment in FEC code where > it says > > /* This does 16 byte alignment, exactly what we need. > * The packet length includes FCS, but we don't want to > * include that when passing upstream as it messes up > * bridging applications. > */ > while receiving the frames, I checked my modified code w.r.t the length, > since I was not knowing the receive lengthn while allocating for the > RX ring, I did with a maximum of 2048 bytes length and called the skb_put > to reserve 2048 bytes for data, calling of the skb_put also updated the > skb->len field with 2048, this was causing the problem, the bridge module > was trying to send the frame with 2048 bytes even though the actual length > was less number of bytes, so even after sending it to the FEC, the frame was > getting transmitted successfully. So I updated the actual length to the > skb->len field in the rx ISR, the problem is solved now. > > But I'm facing problems during load time in bridge mode > PC-1 >eth0 [Bridge machine] eth1 > PC-2 > With the above setup I initiate 1500 pings each of 1400 bytes > from PC1 to PC2, then the ping sequence starts, but after some time > say some 25-35(all 1500 instances) sequences all of a sudden no > ping reply is received for any request. > At that time if I observe in the Bridge machine cat /proc/interrupts > the fec interrupts will not get updated there(initially it used to) > again it resumes after some 45-60 seconds and the sequence repeats. > Dunno what's happening with in the FEC if configured in bridge mode > any clue on this, Thanks a lakh in advance. If I remember correctly, this is what you get when the invalidation of the skb buffers isn't working properly. Guessing again, but you seem to split up the page into two buffers of len 2048, but you flush/invalidate the whole page. That won't work. You are much better off by just using plain skb allocation and invalidate the buffer before passing it to the CPM/FEC. Just make sure that the allocated buffer has a cache aligned length. This is what I did long time ago and it worked out perfectly. Jocke ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
