In-Reply-To: <[EMAIL PROTECTED]> On Mon, 18 Dec 2006 20:05:35 +0100, Nicholas Mc Guire wrote:
> I have a phenomena that I don't quite understand. gdbserver forks and > after setting ptrace (PTRACE_TRACEME, 0, 0, 0); it then execv > (program, allargs); when this child process hits ptrace_stoped (breakpoint > it does the following in kernel space: > > pid > 1 559 5 1242 ptrace_stop > 3 6 2 1242 | do_notify_parent_cldstop > 4 3 2 1242 | | __group_send_sig_info > 5 1 1 1242 | | | handle_stop_signal > 7 0 0 1242 | | | sig_ignored > 8 1 0 1242 | | __wake_up_sync > 8 1 1 1242 | | | __wake_up_common > 10 547 541 1242 | schedule > 10 2 2 1242 | | profile_hit > 13 1 1 1242 | | sched_clock > 15 1 0 1242 | | deactivate_task > 15 1 1 1242 | | | dequeue_task > 19 2 2 0 | | __switch_to > 24 574 574 0 default_idle > So basically child signals -> delayed to next tick -> parent wakes up. What do the first three columns represent? Do you see __wake_up_common() calling default_wake_function()? Can you trace through schedule() and see exactly how it decides to run the idle task instead of the newly-woken parent? Exactly what path does it take? (And which kernel version is this?) -- MBTI: IXTP - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
