Messages in this thread | | | Date | Sun, 26 Oct 2008 13:42:39 +0100 | From | Heiko Carstens <> | Subject | Re: [PULL] module, param and stop_machine patches |
| |
On Sun, Oct 26, 2008 at 07:16:16PM +1100, Rusty Russell wrote: > On Sunday 26 October 2008 09:33:43 Linus Torvalds wrote: > > On Sun, 26 Oct 2008, Rusty Russell wrote: > > > Thanks, Heiko tracked this down; he's probably sleeping now but Hugh and > > > Walt reported this fixes it for them and it makes sense. > > I'm not seeing any "tracked it down". > He tracked it down to moving init_workqueues() too early, so he moved that > back. > > > And it then mixes things up with 'stop_machine_init()' mess. Why does that > > need to run so early? > > The S/390 guys want to run it stop_machine v. early, so when Heiko introduced > stop_machine_init() he made it an early_initcall(). > > > IOW, I don't think that patch is anything but a "hey, test if it works > > with this". None of the changes or the problems are explained. > > Indeed. > > Turns out it's the cpu_online_map difference. If init_workqueues() is called > too early, only the boot cpu is set. We then only create_workqueue_thread() > for the boot cpu. > > If CONFIG_HOTPLUG_CPU=y, it's fine since the hotplug callback will create the > workqueue threads for the other cpus as they come up. Without it, the kevent > workqueues on non-boot cpus don't get processed. > > Still boots for me, but was a bit sick (varying, but no keyboard was one > symptom).
Yes, it's all my fault. I always think in terms of CONFIG_HOTPLUG_CPU=y, so I couldn't make any sense of the bug reports and just reverted the init_workqueues() call move and added an explicit stop_machine_init() call, so that we don't depend on linkage order. Thanks for tracking it down, Rusty!
> > Nor do I see a sign-off from Heiko on it.
Signed-off-by: Heiko Carstens <heiko.carstens@de.ibm.com>
But I guess you don't need that anymore since you already committed a fix for this.
Thanks, Heiko
| |