CPU hotplug boot change for IA64

What's the reason for putting cpu_initialize in setup.c instead of smp.c? Also, I much prefer to have all global variables declared in header files; especially for special things that are marked __init or __devinit, etc. Nothing worse than someone accidentally trying to use the variable after its gone. (Yes, there are other offenders, but that's no reason to add to the problem.)

Sorry, I missed to remove that. :-(
cpu_initialized (or something like that) is needed when CPU Hot Plug is implemented.
__cpu_up() must detect that the CPU has already been initialized and but offlined or the CPU hasn't been initialized. But for 2.5.29, such the variable isn't necessary.
And as you pointed out, it should not be in setup.c. I'll update the patch and send it later.

Bit for CPU#0 on cpu_online_map was set at smp_boot_cpus() before. But on the 2.5.29, place of calling smp_boot_cpus() is changed to later timing and this seems to make a chance that smp_call_function() is called before setting cpu_online_map, (I guess.)
In that case, smp_call_function won't return because num_online_cpus() returns 0 and the system will hang.

I have an experience of this problem only on a large system like Tiger, but it may occur on another system.

Rusty, I guess this modification should be needed for i386, too.

Quoted 1 line

Rusty, I guess this modification should be needed for i386, too.

You should *not* be calling smp_call_function before smp_prepare_cpus.

I know kgdb can do this, but it's a special case.

Hi Rusty,

Quoted 2 lines · On Sat, 03 Aug 2002 13:29:02 +1000 Rusty Russell <[email protected]> wrote:

Quoted 1 line

Rusty, I guess this modification should be needed for i386, too.

Quoted 3 lines

You should *not* be calling smp_call_function before smp_prepare_cpus.

I know kgdb can do this, but it's a special case.

OK.
I cannot remember who was calling smp_call_function, but I think it might be kdb. I'm using kdb for debugging in usual.

In message <[email protected]> you write:

Quoted 7 lines

Hi Rusty,

Quoted 2 lines · On Sat, 03 Aug 2002 13:29:02 +1000 Rusty Russell <[email protected]> wrote:

Quoted 1 line

Rusty, I guess this modification should be needed for i386, too.

Quoted 7 lines

Quoted 3 lines

You should *not* be calling smp_call_function before smp_prepare_cpus.

I know kgdb can do this, but it's a special case.

OK.
I cannot remember who was calling smp_call_function, but I think it might be kdb. I'm using kdb for debugging in usual.

Yes, in which case the fix I asked Andrew Morton to use was:

        /* Before smp_prepare_cpus, cpu_online not usable */
        if (num_online_cpus() > 1)
                smp_call_function(...)

Hi David,

I removed cpu_initialized and fixed several bugs. I tested SMP and UP kernels on 2-way Bigsur. Please let me know if there is any problem on the patch.

Quoted 3 lines

I removed cpu_initialized and fixed several bugs. I tested SMP and UP kernels on 2-way Bigsur. Please let me know if there is any problem on the patch.

The patch looks fine. Before applying it to 2.5.29 my BigSur ended up with no tasks beeing scheduled to cpu#1 and no migration_task and ksoftirqd for the same cpu. But the system came up. After applying it the system hangs in the boot sequence right after "Freeing unused kernel memory". But CPU#1 was woken up correctly. Sorry, have no kdb to be able to tell you more...

Does anybody else have these problems?

The patch looks fine. Before applying it to 2.5.29 my BigSur ended up with no tasks beeing scheduled to cpu#1 and no migration_task and ksoftirqd for the same cpu.

But the system came up. After applying it
the system hangs in the boot sequence right after "Freeing unused kernel memory". But CPU#1 was woken up correctly. Sorry, have no kdb to be able to tell you more...

Does anybody else have these problems?