In init/main.c, do_basic_setup() we have:
start_context_thread();
do_initcalls();
start_context_thread() calls kernel_thread() to start the keventd
thread. Then do_initcalls() calls all the init functions and
finishes by calling flush_scheduled_tasks(). This function ends
up calling schedule_task() which checks if keventd is running.
With a very stripped down kernel, it seems possible that do_initcalls()
can complete without context_thread() having had a chance to run (and
set the flag that keventd is running).
Right now, in the Linux/VAX project, I'm working with a very stripped
down kernel and I'm seeing this behaviour. Depending on what I enable
in the .config, I can get schedule_task() to fail with:
schedule_task(): keventd has not started
When starting bdflush and kupdated, bdflush_init() uses a semaphore to
make sure that the threads have run before continuing. Shouldn't
start_context_thread() do something similar?
Or am I missing something?
Thanks,
Kenn
-
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/
