[osol-discuss] [appliances-discuss] Multi core support

[Gavin Maltby]

Hi,

Martin Bochnig wrote:

[cut]

> In your case it appears, as if the 2nd core has not been correctly
> initialized indeed (or as if the 2nd core has been shut down /
> disabled).
> Could it be that the CPUID of your CoreDuo2 2.4GHz chip is just too
> brand new, and hence not in the kernel's cpu-identification code yet?

Are we booting native here - i.e. on metal, no virtualisation software etc?
Which distro is this (I've just entered on the cross-post to -discuss
so missing some history).

We're setting ncpu per core etc so it looks like CPUID is telling us
what you'd expect to see - HTT etc.

> The CPU identification detection mechanism code code can be tricky, I
> recall that it has been a bit difficult to make qemu-system-x86_64 be
> recognized as AMD64-capable 64bit cpu at first (by any Solaris 10 /11
> kernel), Solaris only saw it as 32 bit 686. The Linux kernel does not
> have so sophisticated checks and recognized it from the outset on
> (also due to the fact, that most qemu.org developers still use linUX
> as their primary devel platform).
> But Juergen Keil soon found a fix for Solaris, back in October 2006
> (for exact details and the files involved see qemu-discuss archives).
> 
>  Regards,
> %martin
> 
>> uname -a
>> SunOS eon 5.11 snv_109 i86pc i386 i86pc
>>
>> grep cpu /var/adm/messages
>> Mar 14 22:21:52 eon unix: [ID 126719 kern.info] features: 635f7fff<ssse3,cpuid,mwait,cmp,cx16,sse3,nx,asysc,sse2,sse,sep,pat,cx8,pae,mca,mmx,cmov,de,pge,mtrr,msr,tsc,lgpg>
>> Mar 14 22:21:52 eon genunix: [ID 408114 kern.info] /cpus (cpunex0) online
>> Mar 14 22:21:52 eon cpudrv: [ID 569748 kern.info] NOTICE: cpu_acpi: _TSS package not found.
>> Mar 14 22:21:52 eon cpudrv: [ID 227567 kern.warning] WARNING: cpu_acpi: error parsing _TSS for CPU instance 0
>> Mar 14 22:21:52 eon cpudrv: [ID 888440 kern.warning] WARNING: cpudrv_mach_pm_init: instance 0: unable to initialize T-state support
>> Mar 14 22:21:52 eon cpunex: [ID 114370 kern.info] cpu0 at cpus0
>> Mar 14 22:21:52 eon genunix: [ID 408114 kern.info] /cpus/cpu at 0 (cpudrv0) online
>> Mar 14 22:21:53 eon unix: [ID 950921 kern.info] cpu0: x86 (chipid 0x0 GenuineIntel 6FB family 6 model 15 step 11 clock 2400 MHz)
>> Mar 14 22:21:53 eon unix: [ID 950921 kern.info] cpu0: Intel(r) Core(tm)2 Quad CPU    Q6600  @ 2.40GHz

Could you do the following in mdb -k:

1) So we can see your NCPU at compile time:

::print -at cpuset_t

I'd expect:

 > ::print -at cpuset_t
{
     0 ulong_t [4] cpub
}

2) Assuming no hypervisor etc look at the pcplusmp view of the world.  This is
    a bitmask of local apic ids discovered from our read of the ACPI MADT
    table:

apic_cpumask::print

For example of my 2 x dual core:

 > apic_cpumask::print
{
     cpub = [ 0xf, 0, 0, 0 ]
}

With 2 x quadcore we expect to see 8 bits set in the mask.

3) Now see what was left after attempted mp startup:

use_mp/D

(if shows a zero value that will explain a lot!)

mp_cpus::print

We expect to see the apic_cpumask with the bit for the boot cpu cleared.
eg on my system:

 > mp_cpus::print
{
     cpub = [ 0xe, 0, 0, 0 ]
}

(bit 0 for apic id 0 cleared).

Note that in start_other_cpus we set clear bits from mp_cpus for
cpus for which start_cpu() fails.

You could also look around start_other_cpus and related code
and breakpoint during boot under kmdb.

Cheers

Gavin