Re: [PATCH v2] powerpc: Add i8042 keyboard and mouse irq parsing
Grant Likely wrote:
> On Mon, May 24, 2010 at 10:25 AM, Martyn Welch wrote:
>
>> Currently the irqs for the i8042, which historically provides keyboard and
>> mouse (aux) support, is hardwired in the driver rather than parsing the
>> dts. This patch modifies the powerpc legacy IO code to attempt to parse
>> the device tree for this information, failing back to the hardcoded values
>> if it fails.
>>
>> Signed-off-by: Martyn Welch
>> ---
>>
>> v2: This patch no longer requires the DTS files to be modified, reading the
>> interrupts from the current location as suggested by Grant.
>>
>> arch/powerpc/kernel/setup-common.c | 49
>> ++--
>> drivers/input/serio/i8042-io.h |8 ++
>> 2 files changed, 54 insertions(+), 3 deletions(-)
>>
>> diff --git a/arch/powerpc/kernel/setup-common.c
>> b/arch/powerpc/kernel/setup-common.c
>> index 48f0a00..7f1bb99 100644
>> --- a/arch/powerpc/kernel/setup-common.c
>> +++ b/arch/powerpc/kernel/setup-common.c
>> @@ -94,6 +94,10 @@ struct screen_info screen_info = {
>>.orig_video_points = 16
>> };
>>
>> +/* Variables required to store legacy IO irq routing */
>> +int of_i8042_kbd_irq;
>> +int of_i8042_aux_irq;
>> +
>> #ifdef __DO_IRQ_CANON
>> /* XXX should go elsewhere eventually */
>> int ppc_do_canonicalize_irqs;
>> @@ -558,13 +562,52 @@ void probe_machine(void)
>> /* Match a class of boards, not a specific device configuration. */
>> int check_legacy_ioport(unsigned long base_port)
>> {
>> - struct device_node *parent, *np = NULL;
>> + struct device_node *parent, *np = NULL, *np_aux = NULL;
>>int ret = -ENODEV;
>>
>>switch(base_port) {
>>case I8042_DATA_REG:
>> - if (!(np = of_find_compatible_node(NULL, NULL,
>> "pnpPNP,303")))
>> - np = of_find_compatible_node(NULL, NULL,
>> "pnpPNP,f03");
>> + np = of_find_compatible_node(NULL, NULL, "pnpPNP,303");
>> + if (np) {
>> + /* Interrupt routing in parent node */
>> + parent = of_get_parent(np);
>> + if (parent) {
>> + /*
>> +* Attempt to parse DTS for keyboard irq,
>> +* fallback to standard.
>> +*/
>> + of_i8042_kbd_irq =
>> irq_of_parse_and_map(parent,
>> + 0);
>> + if (!of_i8042_kbd_irq)
>> + of_i8042_kbd_irq = 1;
>> +
>> + of_node_put(parent);
>> + }
>> + }
>> +
>> + np_aux = of_find_compatible_node(NULL, NULL, "pnpPNP,f03");
>> + if (np_aux) {
>> + if (!np) {
>> + of_node_put(np);
>> + np = np_aux;
>> + }
>> +
>> + /* Interrupt routing in parent node */
>> + parent = of_get_parent(np_aux);
>> + if (parent) {
>> + /*
>> +* Attempt to parse DTS for mouse (aux) irq,
>> +* fallback to standard.
>> +*/
>> + of_i8042_aux_irq =
>> irq_of_parse_and_map(parent,
>> + 1);
>> + if (!of_i8042_aux_irq)
>> + of_i8042_aux_irq = 12;
>> +
>> + of_node_put(parent);
>> + }
>> + }
>> +
>>
>
> This seems to be a lot more code that you need. The existing code
> already obtains a pointer to the parent node for you. All you really
> should need to add is the two calls to irq_of_parse_and_map() for
> obtaining the kbd and aux irq numbers.
>
Your right - new patch on it's way.
>>if (np) {
>>parent = of_get_parent(np);
>>of_node_put(np);
>> diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
>> index 847f4aa..8fc8753 100644
>> --- a/drivers/input/serio/i8042-io.h
>> +++ b/drivers/input/serio/i8042-io.h
>> @@ -19,6 +19,11 @@
>> * IRQs.
>> */
>>
>> +#if defined(CONFIG_PPC)
>> +extern int of_i8042_kbd_irq;
>> +extern int of_i8042_aux_irq;
>> +#endif
>>
>
> Please fold these two extern definitions into the #elif
> defined(CONFIG_PPC) block below.
>
Will do.
>> +
>> #ifdef __alpha__
>> # define I8042_KBD_IRQ 1
>> # define I8042_AUX_IRQ (RTC_PORT(0) == 0x170 ? 9 : 12) /* Jensen is special
>> */
>> @@ -27,6 +32,9 @@
>> #include
>> #elif defined(CONFIG_SH_CAYMAN)
>> #include
>> +#elif defined(CONFIG_PPC)
>> +#define I8042_KBD_IRQ of_i8042_kbd_irq
>> +#define I8042_AUX_
mmio_nvram.c users ?
Hi folks ! Anybody aware of anything other than Cell using that driver ? I'd like to make it a platform driver instead of having something that pokes at anything that has a "device_type" set to "nvram" (which is gross and bogus). But I need to know what platforms to fixup... Cheers, Ben. ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[PATCH v3] powerpc: Add i8042 keyboard and mouse irq parsing
Currently the irqs for the i8042, which historically provides keyboard and
mouse (aux) support, is hardwired in the driver rather than parsing the
dts. This patch modifies the powerpc legacy IO code to attempt to parse
the device tree for this information, failing back to the hardcoded values
if it fails.
Signed-off-by: Martyn Welch
---
v2: This patch no longer requires the DTS files to be modified, reading the
interrupts from the current location as suggested by Grant.
v3: Code compacted as suggested by Grant.
arch/powerpc/kernel/setup-common.c | 13 +
drivers/input/serio/i8042-io.h |5 +
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 48f0a00..3d169bb 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -94,6 +94,10 @@ struct screen_info screen_info = {
.orig_video_points = 16
};
+/* Variables required to store legacy IO irq routing */
+int of_i8042_kbd_irq;
+int of_i8042_aux_irq;
+
#ifdef __DO_IRQ_CANON
/* XXX should go elsewhere eventually */
int ppc_do_canonicalize_irqs;
@@ -567,6 +571,15 @@ int check_legacy_ioport(unsigned long base_port)
np = of_find_compatible_node(NULL, NULL, "pnpPNP,f03");
if (np) {
parent = of_get_parent(np);
+
+ of_i8042_kbd_irq = irq_of_parse_and_map(parent, 0);
+ if (!of_i8042_kbd_irq)
+ of_i8042_kbd_irq = 1;
+
+ of_i8042_aux_irq = irq_of_parse_and_map(parent, 1);
+ if (!of_i8042_aux_irq)
+ of_i8042_aux_irq = 12;
+
of_node_put(np);
np = parent;
break;
diff --git a/drivers/input/serio/i8042-io.h b/drivers/input/serio/i8042-io.h
index 847f4aa..5d48bb6 100644
--- a/drivers/input/serio/i8042-io.h
+++ b/drivers/input/serio/i8042-io.h
@@ -27,6 +27,11 @@
#include
#elif defined(CONFIG_SH_CAYMAN)
#include
+#elif defined(CONFIG_PPC)
+extern int of_i8042_kbd_irq;
+extern int of_i8042_aux_irq;
+# define I8042_KBD_IRQ of_i8042_kbd_irq
+# define I8042_AUX_IRQ of_i8042_aux_irq
#else
# define I8042_KBD_IRQ 1
# define I8042_AUX_IRQ 12
--
Martyn Welch (Principal Software Engineer) | Registered in England and
GE Intelligent Platforms | Wales (3828642) at 100
T +44(0)127322748| Barbirolli Square, Manchester,
E martyn.we...@ge.com| M2 3AB VAT:GB 927559189
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mmio_nvram.c users ?
On Tue, May 25, 2010 at 05:43:59PM +1000, Benjamin Herrenschmidt wrote: > Anybody aware of anything other than Cell using that driver ? > > I'd like to make it a platform driver instead of having something that > pokes at anything that has a "device_type" set to "nvram" (which is > gross and bogus). But I need to know what platforms to fixup... The PowerStation is also using it. Adrian ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mmio_nvram.c users ?
One day I'll manage to hit "Reply" or "Reply All" correctly... Benjamin Herrenschmidt wrote: > Hi folks ! > > Anybody aware of anything other than Cell using that driver ? > > I'd like to make it a platform driver instead of having something that > pokes at anything that has a "device_type" set to "nvram" (which is > gross and bogus). But I need to know what platforms to fixup... > > We do on our boards, that would currently be the sbc310, sbc610 and ppc9a (all FSL 86xx based boards). I also have 2 other boards I'm currently working on that will also use that driver. Martyn > Cheers, > Ben. > > > ___ > Linuxppc-dev mailing list > Linuxppc-dev@lists.ozlabs.org > https://lists.ozlabs.org/listinfo/linuxppc-dev > -- Martyn Welch (Principal Software Engineer) | Registered in England and GE Intelligent Platforms | Wales (3828642) at 100 T +44(0)127322748| Barbirolli Square, Manchester, E martyn.we...@ge.com| M2 3AB VAT:GB 927559189 ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 0/4] PPC64-HWBKPT: Hardware Breakpoint interfaces - ver XXI
Hi All, Please find a new version of the hw-breakpoint patchset with changes as described below. The patchset, passes when tested against breakpoints caused by user-space instructions but fails against kernel-space instructions (as a result of emulate_step() failure). They should begin to work fine with further enhancements to emulate_step(). Changelog - ver XXI (Version XIX: linuxppc-dev ref:20100524103136.ga8...@in.ibm.com) - Decision to emulate an instruction is now based on whether the causative instruction is in user_mode() or not. - Breakpoints don't have to be cleared during sigreturn. A 'double-hit' on hw_breakpoint_handler() is harmless for non-ptrace instructions. - Minor changes to enhance code brevity. Kindly let me know your comments. Thanks, K.Prasad Changelog - ver XX (Version XIX: linuxppc-dev ref: 20100524040137.ga20...@in.ibm.com) - Non task-bound breakpoints will only be emulated. Breakpoint will be unregistered with a warning if emulation fails. Changelog - ver XIX (Version XVIII: linuxppc-dev ref: 20100512033055.ga6...@in.ibm.com) - Increased coverage of breakpoints during concurrent alignment_exception and signal handling (which previously had 'blind-spots'). - Support for kernel-thread breakpoints and kernel-space breakpoints inside the context of a user-space process. - Patches re-based to commit f4b87dee923342505e1ddba8d34ce9de33e75050, thereby necessitating minor changes to arch_validate_hwbkpt_settings(). Changelog - ver XVIII (Version XVII: linuxppc-dev ref: 20100414034340.ga6...@in.ibm.com) - Slight code restructuring for brevity and coding-style corrections. - emulate_single_step() now notifies DIE_SSTEP to registered handlers; causes single_step_dabr_instruction() to be invoked after alignment_exception. - hw-breakpoint restoration variables are cleaned-up before unregistration through arch_unregister_hw_breakpoint(). - SIGTRAP is no longer generated for non-ptrace user-space breakpoints. Changelog - ver XVII (Version XVI: linuxppc-dev ref: 20100330095809.ga14...@in.ibm.com) - CONFIG_HAVE_HW_BREAKPOINT is now used to define the scope of the new code (in lieu of CONFIG_PPC_BOOK3S_64). - CONFIG_HAVE_HW_BREAKPOINT is now dependant upon CONFIG_PERF_EVENTS and CONFIG_PPC_BOOK3S_64 (to overcome build failures under certain configs). - Included a target in arch/powerpc/lib/Makefile to build sstep.o when HAVE_HW_BREAKPOINT. - Added a dummy definition for hw_breakpoint_disable() when !HAVE_HW_BREAKPOINT. - Tested builds under defconfigs for ppc64, cell and g5 (found no patch induced failures). Changelog - ver XVI (Version XV: linuxppc-dev ref: 20100323140639.ga21...@in.ibm.com) - Used a new config option CONFIG_PPC_BOOK3S_64 (in lieu of CONFIG_PPC64/CPU_FTR_HAS_DABR) to limit the scope of the new code. - Disabled breakpoints before kexec of the machine using hw_breakpoint_disable(). - Minor optimisation in exception-64s.S to check for data breakpoint exceptions in DSISR finally (after check for other causes) + changes in code comments and representation of DSISR_DABRMATCH constant. - Rebased to commit ae6be51ed01d6c4aaf249a207b4434bc7785853b of linux-2.6. Changelog - ver XV (Version XIV: linuxppc-dev ref: 20100308181232.ga3...@in.ibm.com) - Additional patch to disable interrupts during data breakpoint exception handling. - Moved HBP_NUM definition to cputable.h under a new CPU_FTR definition (CPU_FTR_HAS_DABR). - Filtering of extraneous exceptions (due to accesses outside symbol length) is by-passed for ptrace requests. - Removed flush_ptrace_hw_breakpoint() from __switch_to() due to incorrect coding placement. - Changes to code comments as per community reviews for previous version. - Minor coding-style changes in hw_breakpoint.c as per review comments. - Re-based to commit ae6be51ed01d6c4aaf249a207b4434bc7785853b of linux-2.6 Changelog - ver XIV (Version XIII: linuxppc-dev ref: 20100215055605.gb3...@in.ibm.com) - Removed the 'name' field from 'struct arch_hw_breakpoint'. - All callback invocations through bp->overflow_handler() are replaced with perf_bp_event(). - Removed the check for pre-existing single-stepping mode in hw_breakpoint_handler() as this check is unreliable while in kernel-space. Side effect of this change is the non-triggering of hw-breakpoints while single-stepping kernel through KGDB or Xmon. - Minor code-cleanups and addition of comments in hw_breakpoint_handler() and single_step_dabr_instruction(). - Re-based to commit 25cf84cf377c0aae5dbcf937ea89bc7893db5176 of linux-2.6 Changelog - ver XIII (Version XII: linuxppc-dev ref: 20100121084640.ga3...@in.ibm.com) - Fixed a bug for user-space breakpoints (triggered following the failure of a breakpoint request). - Re-based on commit 724e6d3fe8003c3f60bf404bf2
[Patch 1/4] Allow arch-specific cleanup before breakpoint unregistration
Certain architectures (such as PowerPC Book III S) have a need to cleanup
data-structures before the breakpoint is unregistered. This patch introduces
an arch-specific hook in release_bp_slot() along with a weak definition in
the form of a stub funciton.
Signed-off-by: K.Prasad
---
kernel/hw_breakpoint.c | 12
1 file changed, 12 insertions(+)
Index: linux-2.6.ppc64_test/kernel/hw_breakpoint.c
===
--- linux-2.6.ppc64_test.orig/kernel/hw_breakpoint.c
+++ linux-2.6.ppc64_test/kernel/hw_breakpoint.c
@@ -242,6 +242,17 @@ toggle_bp_slot(struct perf_event *bp, bo
}
/*
+ * Function to perform processor-specific cleanup during unregistration
+ */
+__weak void arch_unregister_hw_breakpoint(struct perf_event *bp)
+{
+ /*
+* A weak stub function here for those archs that don't define
+* it inside arch/.../kernel/hw_breakpoint.c
+*/
+}
+
+/*
* Contraints to check before allowing this new breakpoint counter:
*
* == Non-pinned counter == (Considered as pinned for now)
@@ -339,6 +350,7 @@ void release_bp_slot(struct perf_event *
{
mutex_lock(&nr_bp_mutex);
+ arch_unregister_hw_breakpoint(bp);
__release_bp_slot(bp);
mutex_unlock(&nr_bp_mutex);
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 2/4] PPC64-HWBKPT: Implement hw-breakpoints for PowerPC BookIII S
Implement perf-events based hw-breakpoint interfaces for PowerPC Book III S
processors. These interfaces help arbitrate requests from various users and
schedules them as appropriate.
Signed-off-by: K.Prasad
---
arch/powerpc/Kconfig |1
arch/powerpc/include/asm/cputable.h |4
arch/powerpc/include/asm/hw_breakpoint.h | 73 ++
arch/powerpc/include/asm/processor.h |8
arch/powerpc/kernel/Makefile |1
arch/powerpc/kernel/hw_breakpoint.c | 338 +++
arch/powerpc/kernel/machine_kexec_64.c |3
arch/powerpc/kernel/process.c|6
arch/powerpc/kernel/ptrace.c | 64 +
arch/powerpc/lib/Makefile|1
10 files changed, 499 insertions(+)
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
===
--- /dev/null
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
@@ -0,0 +1,73 @@
+/*
+ * PowerPC BookIII S hardware breakpoint definitions
+ *
+ * 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 2010, IBM Corporation.
+ * Author: K.Prasad
+ *
+ */
+
+#ifndef _PPC_BOOK3S_64_HW_BREAKPOINT_H
+#define _PPC_BOOK3S_64_HW_BREAKPOINT_H
+
+#ifdef __KERNEL__
+#ifdef CONFIG_HAVE_HW_BREAKPOINT
+
+struct arch_hw_breakpoint {
+ u8 len; /* length of the target data symbol */
+ int type;
+ unsigned long address;
+};
+
+#include
+#include
+#include
+
+static inline int hw_breakpoint_slots(int type)
+{
+ return HBP_NUM;
+}
+struct perf_event;
+struct pmu;
+struct perf_sample_data;
+
+#define HW_BREAKPOINT_ALIGN 0x7
+/* Maximum permissible length of any HW Breakpoint */
+#define HW_BREAKPOINT_LEN 0x8
+
+extern int arch_bp_generic_fields(int type, int *gen_bp_type);
+extern int arch_check_bp_in_kernelspace(struct perf_event *bp);
+extern int arch_validate_hwbkpt_settings(struct perf_event *bp);
+extern int hw_breakpoint_exceptions_notify(struct notifier_block *unused,
+ unsigned long val, void *data);
+int arch_install_hw_breakpoint(struct perf_event *bp);
+void arch_uninstall_hw_breakpoint(struct perf_event *bp);
+void hw_breakpoint_pmu_read(struct perf_event *bp);
+extern void flush_ptrace_hw_breakpoint(struct task_struct *tsk);
+
+extern struct pmu perf_ops_bp;
+extern void ptrace_triggered(struct perf_event *bp, int nmi,
+ struct perf_sample_data *data, struct pt_regs *regs);
+static inline void hw_breakpoint_disable(void)
+{
+ set_dabr(0);
+}
+
+#else /* CONFIG_HAVE_HW_BREAKPOINT */
+static inline void hw_breakpoint_disable(void) { }
+#endif /* CONFIG_HAVE_HW_BREAKPOINT */
+#endif /* __KERNEL__ */
+#endif /* _PPC_BOOK3S_64_HW_BREAKPOINT_H */
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
===
--- /dev/null
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
@@ -0,0 +1,338 @@
+/*
+ * HW_breakpoint: a unified kernel/user-space hardware breakpoint facility,
+ * using the CPU's debug registers. Derived from
+ * "arch/x86/kernel/hw_breakpoint.c"
+ *
+ * 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 2010 IBM Corporation
+ * Author: K.Prasad
+ *
+ */
+
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+#include
+
+#include
+#include
+#include
+
+/*
+ * Stores the breakpoints currently in use on each breakpoint address
+ * register for every cpu
+ */
+static DEFINE_PER_CPU(struct per
[Patch 3/4] PPC64-HWBKPT: Handle concurrent alignment interrupts
An alignment interrupt may intervene between a DSI/hw-breakpoint exception
and the single-step exception. Enable the alignment interrupt (through
modifications to emulate_single_step()) to notify the single-step exception
handler for proper restoration of hw-breakpoints.
Signed-off-by: K.Prasad
---
arch/powerpc/kernel/traps.c |7 ++-
1 file changed, 2 insertions(+), 5 deletions(-)
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/traps.c
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/traps.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/traps.c
@@ -602,7 +602,7 @@ void RunModeException(struct pt_regs *re
void __kprobes single_step_exception(struct pt_regs *regs)
{
- regs->msr &= ~(MSR_SE | MSR_BE); /* Turn off 'trace' bits */
+ clear_single_step(regs);
if (notify_die(DIE_SSTEP, "single_step", regs, 5,
5, SIGTRAP) == NOTIFY_STOP)
@@ -621,10 +621,7 @@ void __kprobes single_step_exception(str
*/
static void emulate_single_step(struct pt_regs *regs)
{
- if (single_stepping(regs)) {
- clear_single_step(regs);
- _exception(SIGTRAP, regs, TRAP_TRACE, 0);
- }
+ single_step_exception(regs);
}
static inline int __parse_fpscr(unsigned long fpscr)
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 4/4] PPC64-HWBKPT: Enable hw-breakpoints while handling intervening signals
A signal delivered between a hw_breakpoint_handler() and the
single_step_dabr_instruction() will not have the breakpoint active during
signal handling (since breakpoint will not be restored through single-stepping
due to absence of MSR_SE bit on the signal frame). Enable breakpoints before
signal delivery.
Restore hw-breakpoints if the user-context is altered in the signal handler.
Signed-off-by: K.Prasad
---
arch/powerpc/include/asm/hw_breakpoint.h |2 ++
arch/powerpc/kernel/hw_breakpoint.c | 16
arch/powerpc/kernel/signal.c |3 +++
arch/powerpc/kernel/signal_32.c |2 ++
arch/powerpc/kernel/signal_64.c |2 ++
5 files changed, 25 insertions(+)
Index: linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/include/asm/hw_breakpoint.h
+++ linux-2.6.ppc64_test/arch/powerpc/include/asm/hw_breakpoint.h
@@ -65,9 +65,11 @@ static inline void hw_breakpoint_disable
{
set_dabr(0);
}
+extern void thread_change_pc(struct task_struct *tsk);
#else /* CONFIG_HAVE_HW_BREAKPOINT */
static inline void hw_breakpoint_disable(void) { }
+static inline void thread_change_pc(struct task_struct *tsk) { }
#endif /* CONFIG_HAVE_HW_BREAKPOINT */
#endif /* __KERNEL__ */
#endif /* _PPC_BOOK3S_64_HW_BREAKPOINT_H */
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/hw_breakpoint.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/hw_breakpoint.c
@@ -176,6 +176,22 @@ int arch_validate_hwbkpt_settings(struct
}
/*
+ * Restores the breakpoint on the debug registers.
+ * Invoke this function if it is known that the execution context is about to
+ * change to cause loss of MSR_SE settings.
+ */
+void thread_change_pc(struct task_struct *tsk)
+{
+ struct arch_hw_breakpoint *info;
+
+ if (likely(!tsk->thread.last_hit_ubp))
+ return;
+
+ info = counter_arch_bp(tsk->thread.last_hit_ubp);
+ set_dabr(info->address | info->type | DABR_TRANSLATION);
+}
+
+/*
* Handle debug exception notifications.
*/
int __kprobes hw_breakpoint_handler(struct die_args *args)
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/signal.c
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/signal.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/signal.c
@@ -11,6 +11,7 @@
#include
#include
+#include
#include
#include
@@ -149,6 +150,8 @@ static int do_signal_pending(sigset_t *o
if (current->thread.dabr)
set_dabr(current->thread.dabr);
#endif
+/* Re-enable the breakpoints for the signal stack */
+ thread_change_pc(current);
if (is32) {
if (ka.sa.sa_flags & SA_SIGINFO)
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/signal_64.c
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/signal_64.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/signal_64.c
@@ -33,6 +33,7 @@
#include
#include
#include
+#include
#include "signal.h"
@@ -312,6 +313,7 @@ int sys_swapcontext(struct ucontext __us
|| __copy_to_user(&old_ctx->uc_sigmask,
¤t->blocked, sizeof(sigset_t)))
return -EFAULT;
+ thread_change_pc(current);
}
if (new_ctx == NULL)
return 0;
Index: linux-2.6.ppc64_test/arch/powerpc/kernel/signal_32.c
===
--- linux-2.6.ppc64_test.orig/arch/powerpc/kernel/signal_32.c
+++ linux-2.6.ppc64_test/arch/powerpc/kernel/signal_32.c
@@ -42,6 +42,7 @@
#include
#include
#include
+#include
#ifdef CONFIG_PPC64
#include "ppc32.h"
#include
@@ -996,6 +997,7 @@ long sys_swapcontext(struct ucontext __u
|| put_sigset_t(&old_ctx->uc_sigmask, ¤t->blocked)
|| __put_user(to_user_ptr(mctx), &old_ctx->uc_regs))
return -EFAULT;
+ thread_change_pc(current);
}
if (new_ctx == NULL)
return 0;
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [git pull] Please pull powerpc.git next branch
On Mon, May 24, 2010 at 09:38:14PM -0500, Kumar Gala wrote: >The following changes since commit 99ec28f183daa450faa7bdad6f932364ae325648: > FUJITA Tomonori (1): >powerpc: Remove unused 'protect4gb' boot parameter > >are available in the git repository at: Ben, don't forget I still have some stuff pending that you haven't picked up. josh ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: mmio_nvram.c users ?
On Tue, May 25, 2010 at 05:43:59PM +1000, Benjamin Herrenschmidt wrote:
>Hi folks !
>
>Anybody aware of anything other than Cell using that driver ?
>
>I'd like to make it a platform driver instead of having something that
>pokes at anything that has a "device_type" set to "nvram" (which is
>gross and bogus). But I need to know what platforms to fixup...
Why bother? You could just use either drivers/mtd/devices/{phram.c or slram.c}
and get the same functionality at that point, couldn't you?
josh
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
[Patch 1/4] Allow arch-specific cleanup before breakpoint unregistration
On Tue, 25 May 2010 at 14:43:56 +0530, K.Prasad wrote:
> Certain architectures (such as PowerPC Book III S) have a need to cleanup
> data-structures before the breakpoint is unregistered. This patch introduces
> an arch-specific hook in release_bp_slot() along with a weak definition in
> the form of a stub funciton.
>
> Signed-off-by: K.Prasad
> ---
> kernel/hw_breakpoint.c | 12
> 1 file changed, 12 insertions(+)
My understanding is weak function definitions must appear in a different C
file than their call sites to work on some toolchains.
Andrew, can you confirm the above statement?
> Index: linux-2.6.ppc64_test/kernel/hw_breakpoint.c
> ===
> --- linux-2.6.ppc64_test.orig/kernel/hw_breakpoint.c
> +++ linux-2.6.ppc64_test/kernel/hw_breakpoint.c
> @@ -242,6 +242,17 @@ toggle_bp_slot(struct perf_event *bp, bo
> }
>
> /*
> + * Function to perform processor-specific cleanup during unregistration
> + */
> +__weak void arch_unregister_hw_breakpoint(struct perf_event *bp)
> +{
> + /*
> + * A weak stub function here for those archs that don't define
> + * it inside arch/.../kernel/hw_breakpoint.c
> + */
> +}
> +
> +/*
> * Contraints to check before allowing this new breakpoint counter:
> *
> * == Non-pinned counter == (Considered as pinned for now)
> @@ -339,6 +350,7 @@ void release_bp_slot(struct perf_event *
> {
> mutex_lock(&nr_bp_mutex);
>
> + arch_unregister_hw_breakpoint(bp);
> __release_bp_slot(bp);
>
> mutex_unlock(&nr_bp_mutex);
>
Since the weak version is empty, should it just be delcared (in
a header, put the comment there) and not defined?
milton
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Spinlock lockup lockup in switch_mmu_context and task_rq_lock
Hi, I am running 2.6.29.1 on MPC8572 dual core with SMP enabled on our customized board. I have two applications running. One is to access CPLD registers via PCI bus and then sleep in an endless loop, the other is to send (and of course receive data) via TSEC port in an endless loop. Sooner or later, I will encounter spinlock lockup in both cores. I examined the call traces and found out that it is always the case that one got stuck in switch_mmu_context and the other in task_rq_lock when switching from interrupt context to a waiting process. BUG: spinlock lockup on CPU#0, diag/31023, c0478f64 BUG: spinlock lockup on CPU#1, diag/31016, c18123c0 Call Trace: [edb4d980] [c0007a78] show_stack+0x48/0x16c (unreliable) [edb4d9b0] [c01c1a48] _raw_spin_lock+0x1b0/0x1c4 [edb4d9f0] [c0348e7c] _spin_lock+0x10/0x20 [edb4da00] [c002f0c8] task_rq_lock+0x50/0x94 [edb4da30] [c0035430] try_to_wake_up+0xb0/0x214 [edb4da60] [c00b99ec] pollwake+0x64/0x74 [edb4dab0] [c0037970] __wake_up_common+0x5c/0xa0 [edb4dae0] [c0037a6c] __wake_up_sync+0x48/0x68 [edb4db10] [c0272aa8] sock_def_write_space+0xac/0xbc [edb4db30] [c0271e48] sock_wfree+0x98/0x9c [edb4db50] [c0274bd0] skb_release_head_state+0x8c/0xa8 [edb4db70] [c0274c04] skb_release_all+0x18/0x30 [edb4db90] [c0274c34] __kfree_skb+0x18/0xec [edb4dbb0] [f106c6fc] csmencaps_rcv+0x474/0x57c [csmencaps] [edb4dbe0] [c027f2c0] netif_receive_skb+0x2ec/0x32c [edb4dc10] [c02167dc] gfar_clean_rx_ring+0x180/0x3dc [edb4dc60] [c0216aa0] gfar_poll+0x68/0x354 [edb4dcc0] [c027fd34] net_rx_action+0x12c/0x1a8 [edb4dcf0] [c00435b0] __do_softirq+0xa8/0x15c [edb4dd40] [c0004348] do_softirq+0x60/0x68 [edb4dd60] [c0043768] irq_exit+0x8c/0x90 [edb4dd80] [c00041e4] do_IRQ+0xd8/0x110 [edb4ddb0] [c00102f4] ret_from_except+0x0/0x18 [edb4de70] [c0014a84] destroy_context+0x3c/0xac [edb4de90] [c003b3fc] __mmdrop+0x3c/0x60 [edb4deb0] [c0035880] finish_task_switch+0xd0/0xd4 [edb4ded0] [c03467b0] __sched_text_start+0x200/0x6b4 [edb4df40] [c00107a8] recheck+0x0/0x24 Call Trace: [e92e9e10] [c0007a78] show_stack+0x48/0x16c (unreliable) [e92e9e40] [c01c1a48] _raw_spin_lock+0x1b0/0x1c4 [e92e9e80] [c0348e7c] _spin_lock+0x10/0x20 [e92e9e90] [c0014700] switch_mmu_context+0x2c/0x35c [e92e9ed0] [c0346778] __sched_text_start+0x1c8/0x6b4 [e92e9f40] [c00107a8] recheck+0x0/0x24 Does anyone have some clue on this? Thanks, Jane ___ Linuxppc-dev mailing list Linuxppc-dev@lists.ozlabs.org https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCH v3] powerpc: Add i8042 keyboard and mouse irq parsing
On Tue, May 25, 2010 at 2:09 AM, Martyn Welch wrote:
> Currently the irqs for the i8042, which historically provides keyboard and
> mouse (aux) support, is hardwired in the driver rather than parsing the
> dts. This patch modifies the powerpc legacy IO code to attempt to parse
> the device tree for this information, failing back to the hardcoded values
> if it fails.
>
> Signed-off-by: Martyn Welch
> ---
>
> v2: This patch no longer requires the DTS files to be modified, reading the
> interrupts from the current location as suggested by Grant.
>
> v3: Code compacted as suggested by Grant.
>
> arch/powerpc/kernel/setup-common.c | 13 +
> drivers/input/serio/i8042-io.h | 5 +
> 2 files changed, 18 insertions(+), 0 deletions(-)
>
> diff --git a/arch/powerpc/kernel/setup-common.c
> b/arch/powerpc/kernel/setup-common.c
> index 48f0a00..3d169bb 100644
> --- a/arch/powerpc/kernel/setup-common.c
> +++ b/arch/powerpc/kernel/setup-common.c
> @@ -94,6 +94,10 @@ struct screen_info screen_info = {
> .orig_video_points = 16
> };
>
> +/* Variables required to store legacy IO irq routing */
> +int of_i8042_kbd_irq;
> +int of_i8042_aux_irq;
> +
> #ifdef __DO_IRQ_CANON
> /* XXX should go elsewhere eventually */
> int ppc_do_canonicalize_irqs;
> @@ -567,6 +571,15 @@ int check_legacy_ioport(unsigned long base_port)
> np = of_find_compatible_node(NULL, NULL, "pnpPNP,f03");
> if (np) {
> parent = of_get_parent(np);
> +
> + of_i8042_kbd_irq = irq_of_parse_and_map(parent, 0);
> + if (!of_i8042_kbd_irq)
> + of_i8042_kbd_irq = 1;
> +
> + of_i8042_aux_irq = irq_of_parse_and_map(parent, 1);
> + if (!of_i8042_aux_irq)
> + of_i8042_aux_irq = 12;
> +
The patch looks okay to me.
BTW, where is the i8042 binding documented? Ben, is this location of
the kbd/mouse irq historical, or is it just something that we happened
to get when the .dts files were first created? Having the irq
specified directly in the kbd or aux nodes would make a lot more
sense, and if this isn't something already nailed down, then it
probably does make sense to move the irq specification, fall back to
the parent node to still support older trees, and with the hard coded
irq numbers as the last resort.
Cheers,
g.
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
Re: [PATCHv2] [RFC] Xilinx Virtex 4 FX Soft FPU support
(cc'ing Josh Boyer and John Linn) On Thu, May 20, 2010 at 4:01 AM, Sergey Temerkhanov wrote: > This patch enables support for Xilinx Virtex 4 FX singe-float FPU. > > Changelog v1->v2: > -Added MSR_AP bit definition > -Renamed CONFIG_XILINX_FPU to CONFIG_XILINX_SOFTFPU, moved it to > 'Platform support' and made it Virtex4-FX-only. > -Changed SAVE_FPR/REST_FPR definition style. > > Caveats: > - Hard-float binaries which rely on in-kernel math emulation will give > wrong results since they expect 64-bit double-precision instead of 32-bit > single-precision numbers which Xilinx V4-FX Soft FPU produces. > > Regards, Sergey Temerkhanov > Hi Sergey. Comments below. First off, see if you can use 'git mail' or some other way to inline your patches. Patches as attachments are awkward to deal with and the patch description is getting separated from the patch itself. > Signed-off-by: Sergey Temerkhanov > > diff -r b59861a64e13 arch/powerpc/include/asm/ppc_asm.h > --- a/arch/powerpc/include/asm/ppc_asm.h Thu May 20 13:24:53 2010 +0400 > +++ b/arch/powerpc/include/asm/ppc_asm.h Thu May 20 13:55:10 2010 +0400 > @@ -85,13 +85,21 @@ > #define REST_8GPRS(n, base) REST_4GPRS(n, base); REST_4GPRS(n+4, base) > #define REST_10GPRS(n, base) REST_8GPRS(n, base); REST_2GPRS(n+8, base) > > -#define SAVE_FPR(n, base)stfdn,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) > + > +#ifdef CONFIG_XILINX_SOFTFPU > +#define SAVE_FPR(n, base)stfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) > +#define REST_FPR(n, base)lfs n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) > +#else > +#define SAVE_FPR(n, base)stfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) > +#define REST_FPR(n, base)lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) > +#endif > + Hint: If you don't change the whitespace on the SAVE_FPR() line, then diff will realize it is unchanged and reviewers will have more context queues as to what you are doing. Otherwise, this looks better. > #define SAVE_2FPRS(n, base) SAVE_FPR(n, base); SAVE_FPR(n+1, base) > #define SAVE_4FPRS(n, base) SAVE_2FPRS(n, base); SAVE_2FPRS(n+2, base) > #define SAVE_8FPRS(n, base) SAVE_4FPRS(n, base); SAVE_4FPRS(n+4, base) > #define SAVE_16FPRS(n, base) SAVE_8FPRS(n, base); SAVE_8FPRS(n+8, base) > #define SAVE_32FPRS(n, base) SAVE_16FPRS(n, base); SAVE_16FPRS(n+16, base) > -#define REST_FPR(n, base)lfd n,THREAD_FPR0+8*TS_FPRWIDTH*(n)(base) > + > #define REST_2FPRS(n, base) REST_FPR(n, base); REST_FPR(n+1, base) > #define REST_4FPRS(n, base) REST_2FPRS(n, base); REST_2FPRS(n+2, base) > #define REST_8FPRS(n, base) REST_4FPRS(n, base); REST_4FPRS(n+4, base) > diff -r b59861a64e13 arch/powerpc/include/asm/reg.h > --- a/arch/powerpc/include/asm/reg.h Thu May 20 13:24:53 2010 +0400 > +++ b/arch/powerpc/include/asm/reg.h Thu May 20 13:55:10 2010 +0400 > @@ -30,6 +30,7 @@ > #define MSR_ISF_LG 61 /* Interrupt 64b mode valid on 630 */ > #define MSR_HV_LG60 /* Hypervisor state */ > #define MSR_VEC_LG 25 /* Enable AltiVec */ > +#define MSR_AP_LG25 /* Enable APU */ > #define MSR_VSX_LG 23 /* Enable VSX */ > #define MSR_POW_LG 18 /* Enable Power Management */ > #define MSR_WE_LG18 /* Wait State Enable */ > @@ -71,6 +72,7 @@ > #define MSR_HV 0 > #endif > > +#define MSR_AP __MASK(MSR_AP_LG) /* Enable APU */ Need to be more specific: "Enable Xilinx Virtex 405 APU". Same goes for MSR_AP_LG line above. > #define MSR_VEC __MASK(MSR_VEC_LG) /* Enable AltiVec */ > #define MSR_VSX __MASK(MSR_VSX_LG) /* Enable VSX */ > #define MSR_POW __MASK(MSR_POW_LG) /* Enable Power > Management */ > diff -r b59861a64e13 arch/powerpc/kernel/fpu.S > --- a/arch/powerpc/kernel/fpu.S Thu May 20 13:24:53 2010 +0400 > +++ b/arch/powerpc/kernel/fpu.S Thu May 20 13:55:10 2010 +0400 > @@ -57,6 +57,9 @@ > _GLOBAL(load_up_fpu) > mfmsr r5 > ori r5,r5,MSR_FP > +#ifdef CONFIG_XILINX_SOFTFPU > + orisr5,r5,msr...@h > +#endif > #ifdef CONFIG_VSX > BEGIN_FTR_SECTION > orisr5,r5,msr_...@h > @@ -85,6 +88,9 @@ > toreal(r5) > PPC_LL r4,_MSR-STACK_FRAME_OVERHEAD(r5) > li r10,MSR_FP|MSR_FE0|MSR_FE1 > +#ifdef CONFIG_XILINX_SOFTFPU > + orisr10,r10,msr...@h > +#endif > andcr4,r4,r10 /* disable FP for previous task */ > PPC_STL r4,_MSR-STACK_FRAME_OVERHEAD(r5) > 1: > @@ -94,6 +100,9 @@ > mfspr r5,SPRN_SPRG3 /* current task's THREAD (phys) */ > lwz r4,THREAD_FPEXC_MODE(r5) > ori r9,r9,MSR_FP/* enable FP for current */ > +#ifdef CONFIG_XILINX_SOFTFPU > + orisr9,r9,msr...@h > +#endif > or r9,r9,r4 > #else > ld r4,PACACURRENT(r13) > @@ -124,6 +133,9 @@ > _GLOBAL(giveup_fpu) > mfmsr r5 > ori r5,r5,M
Re: [PATCH v3] powerpc: Add i8042 keyboard and mouse irq parsing
Grant Likely wrote:
On Tue, May 25, 2010 at 2:09 AM, Martyn Welch wrote:
Currently the irqs for the i8042, which historically provides keyboard and
mouse (aux) support, is hardwired in the driver rather than parsing the
dts. This patch modifies the powerpc legacy IO code to attempt to parse
the device tree for this information, failing back to the hardcoded values
if it fails.
Signed-off-by: Martyn Welch
---
v2: This patch no longer requires the DTS files to be modified, reading the
interrupts from the current location as suggested by Grant.
v3: Code compacted as suggested by Grant.
arch/powerpc/kernel/setup-common.c | 13 +
drivers/input/serio/i8042-io.h |5 +
2 files changed, 18 insertions(+), 0 deletions(-)
diff --git a/arch/powerpc/kernel/setup-common.c
b/arch/powerpc/kernel/setup-common.c
index 48f0a00..3d169bb 100644
--- a/arch/powerpc/kernel/setup-common.c
+++ b/arch/powerpc/kernel/setup-common.c
@@ -94,6 +94,10 @@ struct screen_info screen_info = {
.orig_video_points = 16
};
+/* Variables required to store legacy IO irq routing */
+int of_i8042_kbd_irq;
+int of_i8042_aux_irq;
+
#ifdef __DO_IRQ_CANON
/* XXX should go elsewhere eventually */
int ppc_do_canonicalize_irqs;
@@ -567,6 +571,15 @@ int check_legacy_ioport(unsigned long base_port)
np = of_find_compatible_node(NULL, NULL, "pnpPNP,f03");
if (np) {
parent = of_get_parent(np);
+
+ of_i8042_kbd_irq = irq_of_parse_and_map(parent, 0);
+ if (!of_i8042_kbd_irq)
+ of_i8042_kbd_irq = 1;
+
+ of_i8042_aux_irq = irq_of_parse_and_map(parent, 1);
+ if (!of_i8042_aux_irq)
+ of_i8042_aux_irq = 12;
+
The patch looks okay to me.
BTW, where is the i8042 binding documented? Ben, is this location of
the kbd/mouse irq historical,
i8042 is, of course, the legacy PC keyboard interrupt controller, and
the IRQs that it generates on behalf of its attached keyboard and mouse
have always been 1 and 12 on the PC platforms that drive the hardware
designs of junk I/O chips. By the time that PowerPC came on the market,
the i8042 functionality was always implemented as a subsystem within a
much larger "SuperIO" chip, which often included the (legacy PC)
interrupt controller functionality. Those SuperIO chips let you move
the IRQ numbers around for some of the included devices, but I don't
remember whether or not you could move the IRQs for the keyboard and
mouse. Even if you could, "nobody" ever did it, because people were so
accustomed to 1 and 12 being keyboard and mouse that changing them would
just cause too much confusion. There was also the issue of setting the
edge/level and polarity correctly for the various IRQs. Moving the
kbd/mouse IRQs would have a ripple effect on other old-and-dusty code
that nobody wanted to touch.
The design of PReP (PowerPC Reference Platform) was amusing to watch.
Apple was wanting to make it into a 68K Macintosh I/O system with a
PowerPC grafted in, while IBM wanted a conventional PC with a PowerPC
grafted in. IBM stacked the committee and basically got what they
wanted - a PC with a different CPU chip. At the Comdex show where they
rolled out the PReP spec, Apple had their own announcement to make -
Apple wasn't going to use PReP. So IBM's power play backfired.
The PReP committee (consisting of representatives from IBM, Apple,
Motorola, and a few other bit players like myself) then went into panic
mode, and came out with CHRP. CHRP was PReP with a legacy Macintosh I/O
system bolted onto the side. So you had the worst of both worlds. In
the PReP mode, you had PC-style I/O like IDE, i8042, 8259 interrupt
controller, etc. In the Mac mode, you had SCSI (using a horrible
ancient programming model that nobody else was using anymore), ADB, and
an OpenPIC interrupt controller. The chipsets had to support both sets.
The final shoe dropped 18 months later, when Steve Jobs re-took Apple
and announced that Apple was not in fact going to license MacOS for use
on third-party CHRP machines.
The original binding documents for the PC-style I/O system were driven
from the IBM side. I may have written some of the text (or maybe not; I
forget), but it was IBM who stipulated how it was going to work.
or is it just something that we happened
to get when the .dts files were first created? Having the irq
specified directly in the kbd or aux nodes would make a lot more
sense, and if this isn't something already nailed down, then it
probably does make sense to move the irq specification, fall back to
the parent node to still support older trees, and with the hard coded
irq numbers as the last resort.
Cheers,
g.
___
devicetree-discuss mailing list
devicetree-disc...@lists.ozlabs.org
https://list
Re: Spinlock lockup lockup in switch_mmu_context and task_rq_lock
On Tue, 2010-05-25 at 09:15 -0500, Li, Jianlin (Jianlin) wrote: > Hi, > > I am running 2.6.29.1 on MPC8572 dual core with SMP enabled on our customized > board. > > I have two applications running. One is to access CPLD registers via PCI bus > and then sleep in an endless loop, the other is to send (and of course > receive data) via TSEC port in an endless loop. > > Sooner or later, I will encounter spinlock lockup in both cores. > > I examined the call traces and found out that it is always the case that one > got stuck in switch_mmu_context and the other in task_rq_lock when switching > from interrupt context to a waiting process. This has been fixed since then. I suggest you look at the git changes to mmu_context_nohash.c after 2.6.29 and you'll find the fix quickly. Cheers, Ben. > BUG: spinlock lockup on CPU#0, diag/31023, c0478f64 > BUG: spinlock lockup on CPU#1, diag/31016, c18123c0 > Call Trace: > [edb4d980] [c0007a78] show_stack+0x48/0x16c (unreliable) > [edb4d9b0] [c01c1a48] _raw_spin_lock+0x1b0/0x1c4 > [edb4d9f0] [c0348e7c] _spin_lock+0x10/0x20 > [edb4da00] [c002f0c8] task_rq_lock+0x50/0x94 > [edb4da30] [c0035430] try_to_wake_up+0xb0/0x214 > [edb4da60] [c00b99ec] pollwake+0x64/0x74 > [edb4dab0] [c0037970] __wake_up_common+0x5c/0xa0 > [edb4dae0] [c0037a6c] __wake_up_sync+0x48/0x68 > [edb4db10] [c0272aa8] sock_def_write_space+0xac/0xbc > [edb4db30] [c0271e48] sock_wfree+0x98/0x9c > [edb4db50] [c0274bd0] skb_release_head_state+0x8c/0xa8 > [edb4db70] [c0274c04] skb_release_all+0x18/0x30 > [edb4db90] [c0274c34] __kfree_skb+0x18/0xec > [edb4dbb0] [f106c6fc] csmencaps_rcv+0x474/0x57c [csmencaps] > [edb4dbe0] [c027f2c0] netif_receive_skb+0x2ec/0x32c > [edb4dc10] [c02167dc] gfar_clean_rx_ring+0x180/0x3dc > [edb4dc60] [c0216aa0] gfar_poll+0x68/0x354 > [edb4dcc0] [c027fd34] net_rx_action+0x12c/0x1a8 > [edb4dcf0] [c00435b0] __do_softirq+0xa8/0x15c > [edb4dd40] [c0004348] do_softirq+0x60/0x68 > [edb4dd60] [c0043768] irq_exit+0x8c/0x90 > [edb4dd80] [c00041e4] do_IRQ+0xd8/0x110 > [edb4ddb0] [c00102f4] ret_from_except+0x0/0x18 > [edb4de70] [c0014a84] destroy_context+0x3c/0xac > [edb4de90] [c003b3fc] __mmdrop+0x3c/0x60 > [edb4deb0] [c0035880] finish_task_switch+0xd0/0xd4 > [edb4ded0] [c03467b0] __sched_text_start+0x200/0x6b4 > [edb4df40] [c00107a8] recheck+0x0/0x24 > Call Trace: > [e92e9e10] [c0007a78] show_stack+0x48/0x16c (unreliable) > [e92e9e40] [c01c1a48] _raw_spin_lock+0x1b0/0x1c4 > [e92e9e80] [c0348e7c] _spin_lock+0x10/0x20 > [e92e9e90] [c0014700] switch_mmu_context+0x2c/0x35c > [e92e9ed0] [c0346778] __sched_text_start+0x1c8/0x6b4 > [e92e9f40] [c00107a8] recheck+0x0/0x24 > > Does anyone have some clue on this? > > Thanks, > > Jane > ___ > 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
Re: [Patch 1/4] Allow arch-specific cleanup before breakpoint unregistration
On Tue, May 25, 2010 at 06:39:19AM -0500, Millton Miller wrote:
> On Tue, 25 May 2010 at 14:43:56 +0530, K.Prasad wrote:
> > Certain architectures (such as PowerPC Book III S) have a need to cleanup
> > data-structures before the breakpoint is unregistered. This patch introduces
> > an arch-specific hook in release_bp_slot() along with a weak definition in
> > the form of a stub funciton.
> >
> > Signed-off-by: K.Prasad
> > ---
> > kernel/hw_breakpoint.c | 12
> > 1 file changed, 12 insertions(+)
>
>
> My understanding is weak function definitions must appear in a different C
> file than their call sites to work on some toolchains.
>
Atleast, there are quite a few precedents inside the Linux kernel for
__weak functions being invoked from the file in which they are defined
(arch_hwblk_init, arch_enable_nonboot_cpus_begin and hw_perf_disable to
name a few).
Moreover the online GCC docs haven't any such constraints mentioned.
> Andrew, can you confirm the above statement?
>
> > Index: linux-2.6.ppc64_test/kernel/hw_breakpoint.c
> > ===
> > --- linux-2.6.ppc64_test.orig/kernel/hw_breakpoint.c
> > +++ linux-2.6.ppc64_test/kernel/hw_breakpoint.c
> > @@ -242,6 +242,17 @@ toggle_bp_slot(struct perf_event *bp, bo
> > }
> >
> > /*
> > + * Function to perform processor-specific cleanup during unregistration
> > + */
> > +__weak void arch_unregister_hw_breakpoint(struct perf_event *bp)
> > +{
> > + /*
> > +* A weak stub function here for those archs that don't define
> > +* it inside arch/.../kernel/hw_breakpoint.c
> > +*/
> > +}
> > +
> > +/*
> > * Contraints to check before allowing this new breakpoint counter:
> > *
> > * == Non-pinned counter == (Considered as pinned for now)
> > @@ -339,6 +350,7 @@ void release_bp_slot(struct perf_event *
> > {
> > mutex_lock(&nr_bp_mutex);
> >
> > + arch_unregister_hw_breakpoint(bp);
> > __release_bp_slot(bp);
> >
> > mutex_unlock(&nr_bp_mutex);
> >
>
>
> Since the weak version is empty, should it just be delcared (in
> a header, put the comment there) and not defined?
>
The initial thinking behind defining it in the .c file was, for one,
the function need not be moved (from .h to .c) when other architectures
have a need to populate them. Secondly, given that powerpc (which has a
'strong' definition for arch_unregister_hw_breakpoint()) includes the
header file (in which this can be moved to) I wasn't sure about
possible conflicts.
> milton
> ___
> Linuxppc-dev mailing list
> Linuxppc-dev@lists.ozlabs.org
> https://lists.ozlabs.org/listinfo/linuxppc-dev
Thanks,
K.Prasad
___
Linuxppc-dev mailing list
Linuxppc-dev@lists.ozlabs.org
https://lists.ozlabs.org/listinfo/linuxppc-dev
