Re: [Patch] x86: fix smp_num_siblings on buggy BIOSes

Re: [Patch] x86: fix smp_num_siblings on buggy BIOSes

[Siddha, Suresh B]

On Thu, May 26, 2005 at 10:17:37PM -0700, Andrew Morton wrote:
> "Siddha, Suresh B" <suresh.b.siddha@intel.com> wrote:
> >
> > Appended patch will fix 'smp_num_siblings' value on the systems with
> > buggy bios, which sets number of siblings to '2' even when HT is disabled.
> > (more details are at http://bugzilla.kernel.org/show_bug.cgi?id=4359)
> > 
> > I am planning to do more cleanup in this area (like moving smp_num_siblings 
> > to per cpuinfo) shortly.
> > 
> > But meanwhile, please pickup this patch for 2.6.12.
> > 
> > Signed-off-by: Suresh Siddha <suresh.b.siddha@intel.com>
> > Signed-off-by: Venkatesh Pallipadi <venkatesh.pallipadi@intel.com>
> > 
> > --- linux-2.6.12-rc5/arch/i386/kernel/smpboot.c~	2005-05-25 16:47:56.462416368 -0700
> > +++ linux-2.6.12-rc5/arch/i386/kernel/smpboot.c	2005-05-25 16:48:14.556665624 -0700
> > @@ -1074,8 +1074,10 @@
> >  			cpu_set(cpu, cpu_sibling_map[cpu]);
> >  		}
> >  
> > -		if (siblings != smp_num_siblings)
> > +		if (siblings != smp_num_siblings) {
> >  			printk(KERN_WARNING "WARNING: %d siblings found for CPU%d, should be %d\n", siblings, cpu, smp_num_siblings);
> > +			smp_num_siblings = siblings;
> > +		}
> >  
> >  		if (c->x86_num_cores > 1) {
> >  			for (i = 0; i < NR_CPUS; i++) {
> 
> OK, but be aware that -mm's sibling-map-initializing-rework.patch
> cheerfully deletes all the surrounding code.  So -mm will not have this
> fix.
> 
> There's a completely loony amount of x86 stuff in -mm.

Thanks for this info. I will send a fix for -mm also.

BTW, when do you plan to integrate x86 cpu hotplug patches to mainline?
Depending on that I will plan my "smp_num_siblings" global cleanup.

thanks,
suresh

Re: [Patch] x86: fix smp_num_siblings on buggy BIOSes

[Andrew Morton]

"Siddha, Suresh B" <suresh.b.siddha@intel.com> wrote:
>
> BTW, when do you plan to integrate x86 cpu hotplug patches to mainline?

I guess after the various subsystem trees have merged their stuff
post-2.6.12 (I tend to wait until after they've merged, although sometimes
people are slow and I get bored).  Say, 1-2 weeks after 2.6.12 is released.
And I'd guess 2.6.12 is 1-2 weeks away.

>  Depending on that I will plan my "smp_num_siblings" global cleanup.

gack, OK.  The kexec patches are a major source of x86 churn.  I don't know
if we'll be merging all the kexec stuff for 2.6.13.  Probably we will.