Ingo Molnar wrote: > * Ingo Molnar 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.