Messages in this thread | | | Date | Wed, 07 Jul 2004 12:29:32 +1000 | From | Nick Piggin <> | Subject | Re: 2.6.7-mm6 |
| |
David S. Miller wrote: > On Tue, 6 Jul 2004 16:36:18 -0700 > William Lee Irwin III <wli@holomorphy.com> wrote: > > >>I have it isolated down to the sched-clean-init-idle.patch and >>sched-clean-fork.patch. sched-clean-init-idle.patch fails to build without >>the second of those two applied, so I didn't do any work to narrow it down >>further. > > > One thing to note is that we don't currently call the > wake_up_forked_process() thing in our SMP idle bootup > dispatcher in arch/sparc64/kernel/smp.c > > Perhaps that is somehow related to the problems. > In that case the culprit would be the first patch, > sched-clean-init-idle.patch >
Yes, I missed sparc64 due to the lack of wake_up_forked_process. Dang.
Well, what used to happen is that wake_up_forked_process would put the idle task on the runqueue like a regular process, then init_idle would take it off again.
However after the patch, init_idle simply does all the work itself, and doesn't have to deal with removal from the runqueue. Now sparc64 uses "kernel_thread" to clone its idle tasks, which *does* put the process onto the runqueue. init_idle then also makes it the idle task. This is probably why it blows up.
I guess another small function to remove the task from the runqueue before calling init_idle for those arches that want it would be the way to go.
Sorry, this is my fault. Got to run now, but I'll send a patch to try in a few hours if someone hasn't already. - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
| |