Re: CPU boot problem on 2.6.0-test3-bk8

[Dave Hansen <haveblue@us.ibm.com>]

On Thu, 2003-08-21 at 08:56, Andrew Theurer wrote:
> On Thursday 21 August 2003 09:58, Dave Hansen wrote:
> > On Thu, 2003-08-21 at 07:10, Andrew Theurer wrote:
> > > So we only loop for the actual number processors found in mpparse.c? 
> > > This seems to work for me.
> >
> > I think there's a reason it was done that way.  I think your patch
> > breaks the visws subarch, too.
> >
> > Could you mark up that loop a bit and printk a bit, so we can see which
> > continue you're missing?
> >
> > <pasting patch lazily in email because I can't be bothered to actually copy
> > it from the machine I"m working on> diff -urp
> > linux-2.6.0-test3-clean/arch/i386/kernel/smpboot.c
> > linux-2.6.0-test3-work/arch/i386/kernel/smpboot.c ---
> > linux-2.6.0-test3-clean/arch/i386/kernel/smpboot.c  Wed Aug 20 19:54:29
> > 2003 +++ linux-2.6.0-test3-work/arch/i386/kernel/smpboot.c   Wed Aug 20
> > 20:19:41 2003 @@ -1020,24 +1020,30 @@ static void __init
> > smp_boot_cpus(unsigne
> >         Dprintk("CPU present map: %lx\n",
> > physids_coerce(phys_cpu_present_map));
> >
> >         kicked = 1;
> > -       for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++) {
> > +       for (bit = 0; kicked < NR_CPUS && bit < MAX_APICS; bit++, kicked++)
> 
> This patch (plus your first one) seems to work.  Perhaps the addition of 
> kicked++ above helped?  Attached is the boot log.

I missed that.  But, it's incorrect.  You're doubly incrementing kicked
in the case of CPUs that are booted correctly and getting to kicked >=
NR_CPUS a lot quicker.  That's why you're booting correctly.

Secondly, we can actually boot up to NR_CPUS cpus, and we can *fail* to
boot a lot more than that.  At least that's what the code is trying to
do.  Whether it is "the right thing" is debatable.

-- 
Dave Hansen
haveblue@us.ibm.com