On 2017-03-07 13:39:36 [+0000], Koehrer Mathias (ETAS/ESW3) wrote: > Hi Sebastian, Hi Mathias, > > and 8144 blocks in wait for 8424 which is never completes without additional help > > (like a manual SIGCONT). Right now it looks like the PTRACE_DETACH (syscall > > 101, 11) which should remove the task from ptrace and wakeup did not work but I > > see a wakeup… The wakeup worked (most likely) but since it is stuck I guess that > > there was a second signal it is processing and waiting for gdb. > I do not understand, what that means. > When I run the very same test on a non-rt kernel (or even on a RT kernel with a > preemption model that is not configured as "Fully Preemptible Kernel"), I never see > this issue. I can reproduce the issue on a -RT kernel. I don't really know what the root issue is but it is a problem. We had a ptrace issue if you look into the queue for "ptrace: fix ptrace vs tasklist_lock race" > Also - as mentioned - previously, with older RT preempted kernel versions it is working fine > as well. For me it looks as if the RT preempting on newer kernels somehow has impact > on the way the debugging with gdb works > My expectation (and so far I had the experience) is that a code that is running fine > with a non RT kernel should also run fine with the fully preempted kernel (of course > the timing behavior is different). That is correct - it should work. I've been tracing it for a while now and have no real clue what goes wrong. There a few different ways how it seems to go wrong and the outcome is always that the kernel puts the task in "stop" mode while gdb expects it to run and waits for it. > Regards > > Mathias Sebastian -- To unsubscribe from this list: send the line "unsubscribe linux-rt-users" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
