Hi Sebastian, thanks for the feedback. > > In the error case, there is "prev_state=T|K". > > The t|K should be okay. > > gdb-issue-8145 [001] ....... 9315.877956: sched_process_fork: comm=gdb- > issue pid=8145 child_comm=gdb-issue child_pid=8473 > gdb-issue-8145 [001] d...2.. 9315.877958: sched_wakeup_new: comm=gdb- > issue pid=8473 prio=39 target_cpu=001 > gdb-issue-8145 [001] d...212 9315.877964: sched_wakeup: comm=gdb > pid=8138 prio=120 target_cpu=004 > gdb-issue-8145 [001] .....12 9315.877964: signal_generate: sig=17 errno=0 > code=262148 comm=gdb pid=8138 grp=1 res=0 > gdb-issue-8145 [001] d...2.. 9315.877966: sched_switch: prev_comm=gdb- > issue prev_pid=8145 prev_prio=39 prev_state=t|K ==> next_comm =gdb-issue > next_pid=8473 next_prio=39 > <idle>-0 [004] d...2.. 9315.877990: sched_switch: prev_comm=swapper/4 > prev_pid=0 prev_prio=120 prev_state=R ==> next_comm=gdb next_pid=8138 > next_prio=120 > gdb-8138 [004] ....... 9315.877992: sys_exit: NR 7 = -516 > gdb-8138 [004] .....11 9315.877993: signal_deliver: sig=17 errno=0 > code=262148 sa_handler=5623f7c281e0 sa_flags=14000000 … > > The gdb task deals with each new child and releases it later: > > gdb-8138 [004] ....... 9315.878159: sys_enter: NR 101 (11, 2119, 0, 0, 10, > 30) > gdb-8138 [004] d...2.. 9315.878160: sched_wait_task: comm=gdb-issue > pid=8473 prio=39 > gdb-8138 [004] d...212 9315.878163: sched_wakeup: comm=gdb-issue > pid=8473 prio=39 target_cpu=001 > gdb-8138 [004] ....... 9315.878164: sys_exit: NR 101 = 0 > > later it is gone. So that looks fine. When it hangs > > gdb-issue-8424 [000] d...212 9315.738204: sched_wakeup: comm=gdb > pid=8138 prio=120 target_cpu=004 > (8424 will sched out due to ptrace) > gdb-8138 [004] ....... 9315.738207: sys_exit: NR 61 = 8424 > gdb-8138 [004] ....... 9315.738214: sys_enter: NR 15 (c, 5623f7fff84b, 1, > 0, 8, 30) > gdb-8138 [004] ....... 9315.738215: sys_exit: NR -1 = 8424 > gdb-8138 [004] ....... 9315.738216: sys_enter: NR 101 (11, 20e8, 0, 0, 10, > 30) > gdb-8138 [004] d...2.. 9315.738217: sched_wait_task: comm=gdb-issue > pid=8424 prio=39 > gdb-8138 [004] d...112 9315.738218: sched_waking: comm=gdb-issue > pid=8424 prio=39 target_cpu=000 > gdb-8138 [004] d...212 9315.738220: sched_wakeup: comm=gdb-issue > pid=8424 prio=39 target_cpu=000 > gdb-8138 [004] ....... 9315.738221: sys_exit: NR 101 = 0 > gdb-issue-8144 [000] ....... 9315.738246: sys_exit: NR 56 = 8424 > gdb-issue-8144 [000] ....... 9315.738261: sched_process_wait: comm=gdb- > issue pid=8424 prio=39 > > 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. 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). Regards Mathias ��.n��������+%������w��{.n�����{�����ǫ���ܨ}���Ơz�j:+v�����w����ޙ��&�)ߡ�a����z�ޗ���ݢj��w�f