actually - 2.4.26-3um looks like this already.

int start_uml_skas(void)
{
    start_userspace(0);
    capture_signal_stack();

    init_new_thread_signals(1);
    idle_timer();

    init_task.thread.request.u.thread.proc = start_kernel_proc;
    init_task.thread.request.u.thread.arg = NULL;

so this doesn't play into it as it just put the
idle_timer in 2.6 back where it was in 2.4:

***************
*** 224,232 ****
  {
      start_userspace(0);
      capture_signal_stack();
-     uml_idle_timer();

      init_new_thread_signals(1);

      init_task.thread.request.u.thread.proc = start_kernel_proc;
      init_task.thread.request.u.thread.arg = NULL;
--- 224,232 ----
  {
      start_userspace(0);
      capture_signal_stack();

      init_new_thread_signals(1);
+     uml_idle_timer();



Jeff Dike wrote:

>dbahi@enterasys.com said:
>
>
>>here's a wonderfully infrequent but nagging startup failure that
>>usually has a useless (no stack depth, or just corrupt) backtrace...
>>
>>
>
>You need the uml-enable-the-timer-after-the-timer-handler.patch patch:
>
>	http://www.kernel.org/pub/linux/kernel/people/akpm/patches/2.6/2.6.9-rc2/2.6.9-rc2-mm1/broken-out/uml-enable-the-timer-after-the-timer-handler.patch
>
>				Jeff
>
>
>

--
db