On Wed, Apr 07, 2010 at 06:03:31PM +1000, Benjamin Herrenschmidt wrote:
Ok so too many problems with your last patch, I didn't have time to fix
them all, so it's not going into -next this week.
Please, test with a variety of defconfigs (iseries, cell, g5 for
example), and especially with
Ok so too many problems with your last patch, I didn't have time to fix
them all, so it's not going into -next this week.
Please, test with a variety of defconfigs (iseries, cell, g5 for
example), and especially with CONFIG_PERF_EVENTS not set. There are
issues in the generic header for that
On Tue, Mar 23, 2010 at 04:33:01PM +1100, Paul Mackerras wrote:
On Mon, Mar 08, 2010 at 11:44:48PM +0530, K.Prasad wrote:
@@ -479,6 +483,7 @@ struct task_struct *__switch_to(struct t
old_thread-accum_tb += (current_tb - start_tb);
new_thread-start_tb = current_tb;
On Mon, Mar 08, 2010 at 11:44:48PM +0530, K.Prasad wrote:
@@ -479,6 +483,7 @@ struct task_struct *__switch_to(struct t
old_thread-accum_tb += (current_tb - start_tb);
new_thread-start_tb = current_tb;
}
+ flush_ptrace_hw_breakpoint(current);
#endif
On Fri, Mar 12, 2010 at 05:19:36PM +1100, Benjamin Herrenschmidt wrote:
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
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,54 @@
+#ifndef _PPC64_HW_BREAKPOINT_H
+#define
Implement perf-events based hw-breakpoint interfaces for PPC64 processors.
These interfaces help arbitrate requests from various users and schedules
them as appropriate.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/Kconfig |1
On Fri, Feb 26, 2010 at 02:58:12AM +0100, Frederic Weisbecker wrote:
On Mon, Feb 22, 2010 at 06:47:46PM +0530, K.Prasad wrote:
[snip]
Oh, why does ptrace use a one-shot behaviour in ppc? Breakpoints
only trigger once?
Yes, ptrace breakpoints on PPC64 are designed to trigger once
On Fri, Feb 26, 2010 at 02:58:12AM +0100, Frederic Weisbecker wrote:
On Mon, Feb 22, 2010 at 06:47:46PM +0530, K.Prasad wrote:
The 'name' field here is actually a legacy inherited from x86 code. It
is part of x86's arch-specific hw-breakpoint structure since:
- inspired by the kprobe
On Tue, Feb 23, 2010 at 04:27:15PM +0530, K.Prasad wrote:
On Mon, Feb 22, 2010 at 06:47:46PM +0530, K.Prasad wrote:
On Sun, Feb 21, 2010 at 02:01:37AM +0100, Frederic Weisbecker wrote:
On Mon, Feb 15, 2010 at 11:29:14AM +0530, K.Prasad wrote:
[snipped]
Also, do you think addr/len/type is
On Mon, Feb 22, 2010 at 06:47:46PM +0530, K.Prasad wrote:
The 'name' field here is actually a legacy inherited from x86 code. It
is part of x86's arch-specific hw-breakpoint structure since:
- inspired by the kprobe implementation which accepts symbol name as
input.
- kallsyms_lookup_name()
On Mon, Feb 22, 2010 at 06:47:46PM +0530, K.Prasad wrote:
On Sun, Feb 21, 2010 at 02:01:37AM +0100, Frederic Weisbecker wrote:
On Mon, Feb 15, 2010 at 11:29:14AM +0530, K.Prasad wrote:
[snipped]
Also, do you think addr/len/type is enough to abstract out
any ppc breakpoints?
This looks
On Sun, Feb 21, 2010 at 02:01:37AM +0100, Frederic Weisbecker wrote:
On Mon, Feb 15, 2010 at 11:29:14AM +0530, K.Prasad wrote:
+struct arch_hw_breakpoint {
+ u8 len; /* length of the target symbol */
+ int type;
+ char*name; /* Contains name of
On Mon, Feb 15, 2010 at 11:29:14AM +0530, K.Prasad wrote:
+struct arch_hw_breakpoint {
+ u8 len; /* length of the target symbol */
+ int type;
+ char*name; /* Contains name of the symbol to set bkpt */
+ unsigned long address;
+};
I
Implement perf-events based hw-breakpoint interfaces for PPC64 processors.
These interfaces help arbitrate requests from various users and schedules
them as appropriate.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/Kconfig |1
On Tue, Jan 19, 2010 at 02:03:35AM -0800, Roland McGrath wrote:
It is also not clear to me if disabling pre-emption for the user-space
(albeit for a very tiny time-window) is incorrect and if their side-effects
are known. If otherwise, I think we should choose to operate in pre-empt
safe
Implement perf-events based hw-breakpoint interfaces for PPC64 processors.
These interfaces help arbitrate requests from various users and schedules
them as appropriate.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/Kconfig |1
On Mon, Dec 14, 2009 at 11:26:26AM -0800, Roland McGrath wrote:
snipped
I understand the reason for using stepping. (I have advised in the past
that I thought this magical implicit step logic was too hairy to roll in
under the covers and that a low-level facility expressing the different
On Sun, Dec 13, 2009 at 04:56:48PM -0800, Roland McGrath wrote:
I can't see anything you've done to keep this use of MSR_SE in the
user-mode register state from interfering with user_enable_single_step().
It looks to me like you'd swallow the normal step indications.
Yes, it does unset
Yes, it does unset MSR_SE bit in single_step_dabr_instruction()
irrespective of whether it was previously enabled through
user_enable_single_step(). This could be mitigated with the use of a
separate flag which can be used to conditionally unset MSR_SE, however
given further concerns about
I can't see anything you've done to keep this use of MSR_SE in the
user-mode register state from interfering with user_enable_single_step().
It looks to me like you'd swallow the normal step indications.
Likewise I'm not very clear on the interaction with kprobes, kgdb,
or whatnot for kernel-mode
Implement perf-events based hw-breakpoint interfaces for PPC64 processors.
These interfaces help arbitrate requests from various users and schedules
them as appropriate.
Signed-off-by: K.Prasad pra...@linux.vnet.ibm.com
---
arch/powerpc/Kconfig |1
22 matches
Mail list logo
