Messages in this thread Patch in this message | | | Date | Sat, 12 Dec 2009 15:01:58 -0600 | From | Jason Wessel <> | Subject | Re: [RFC] Fix 2.6.33 x86 regression to kgdb hw breakpoints - due to perf API changes |
| |
Ingo Molnar wrote: > * Ingo Molnar <mingo@elte.hu> wrote: > > >> Hm, the kgdb hw-breakpoint changes freshly put into v2.6.33 look >> pretty broken: [...] >> > > Sorry - i thought for a moment that it was introduced by this recent > change: > > 7f8b7ed: kgdb: Always process the whole breakpoint list on activate or deactivate > > but it's deeper than that indeed. > >
Yes, the broken parts came from the perf merge.
> Basically we have two options: > > A- change kgdb to use the hw-breakpoints highlevel APIs (i'd prefer > that) > >
Right now we can't because the high level code uses all sorts of mutexes and sync points to get the hw breakpoints installs on the various processors. After I re-spun my RFC patch, I found another problem. I do use the high level code to create a block of 4 (struct perf_event **) structures, but doing so ultimately calls the reserve hw breakpoint even though they are marked as disabled when created.
Should I, or can I change that behavior?
The aim of the RFC patch was to allow kgdb to using the arch_install* break point functions directly because they can be used atomically, and the perf code at the high level will still not get a breakpoint if kgdb is already using it that way, and kgdb won't squash a breakpoint that the perf code is using.
In the ideal world the management routines could be the same, but the problem is in the way we want to deal with the break points in kgdb while the master and all slave cpus are effectively stopped.
> B- or keep what we had so far: kgdb overrides existing GDB (and now > perf) breakpoints > This is broken today, because the perf installs itself as the lowest priority.
If kgdb were to get a lower priority there is a way to make it work again using the existing code.
The RFC patch I made aligns things a little better in that at least perf, user space, and kgdb are all pulling from the same low level management code. It has the desirable side effect of making user space hw breakpoints work in conjunction with kernel space hw breakpoints which is something that never worked before.
> I havent noticed that hw-breakpoints lock up under kgdb. >
I don't see the lockups all the time, it happens when using the kgdb test suite from boot with the allyesconfig. Or if you boot the kernel with kgdbts=V1F100.
I think for now we might just consider turning off the hw breakpoint code in kgdb so we don't hang kernels, until this is sorted out. Patch provided.
Jason.
From: Jason Wessel <jason.wessel@windriver.com> Subject: [PATCH] x86,kgdb: disable kgdb hw breakpoints until they are fixed
Using hw breakpoints can hang the kgdb test suite or yeild unpredictable results while debugging due to the recent hw_breakpoint changes in 2.6.33. Until this is fixed, disable kgdb hw breakpoint support.
Signed-off-by: Jason Wessel <jason.wessel@windriver.com> --- arch/x86/kernel/kgdb.c | 1 - 1 file changed, 1 deletion(-)
--- a/arch/x86/kernel/kgdb.c +++ b/arch/x86/kernel/kgdb.c @@ -576,7 +576,6 @@ unsigned long kgdb_arch_pc(int exception struct kgdb_arch arch_kgdb_ops = { /* Breakpoint instruction: */ .gdb_bpt_instr = { 0xcc }, - .flags = KGDB_HW_BREAKPOINT, .set_hw_breakpoint = kgdb_set_hw_break, .remove_hw_breakpoint = kgdb_remove_hw_break, .remove_all_hw_break = kgdb_remove_all_hw_break, | |